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The Shape of Content 



This is a small piece. A simple HTTP interface, called ws-raster, to wrap 
Batiks SVG to PNG 

transcoding http : / /xmlgraphics . apache . org/batik/using/transcoder . html 

functionality. 

Like the ws- 

deCOde http: //www. aaronland.info/weblog/200 8/02/ 05 /fox/index. html#ws- 

decode (2D barcode decoder) endpoint it takes input posted to a URL, turns it in 
to something else and sends it back. Nothing special here but the ability to expose 
some code-magic available mostly-only in Java without having to write everything 
else in Java. I say mostly-only because the Cairo http://cairographics.org/ 
libraries have both support for SVG and bindings for higher-level languages like 
Python. But the cost of being written in C is a twisty maze of dependencies and 
rain-dances to install anything which makes distributing Just-Make-It-Run style 
packages difficult. WS-raster http://aaronland.info/java/ws-raster/ weighs 
in at a hefty 4MB, compressed, which is a little goofy for such spartan functionality 
but that's mostly all of the Batik widgets that come "with batteries included" so that 
it will Just Work® out of the box. 

So, yeah : It takes an SVG file and returns a rasterized version as a PNG file. 
Why? Pirate 

maps http: //www. aaronland.info/weblog/2 008/02 /05/f ox/index. html#ws- 
modestmaps , of course. A way to take a feature -rich online map and boil it down 
to a simple set of landmarks and directions, all of which can be easily printed. 
Consider a popular coffee shop in San Francisco : 
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The first thing you'll notice is that the tiles in the first and second image 
suddenly change; switching from Yahoo! Maps to Open Street Maps. (Actually, if 
you're from San Francisco the first thing you'll notice is that 
Ritual http://flickr.com/photos/tags/ritualroasters/ is really on the 
other side of Hill Street. So it goes with geocoders. They know the shape of the 
elephant but if you ask a geocoder where to feed the elephant you may end up 
sticking the peanut in. ..well, never mind. The point of these things is to get most of 
the way there. If you can't figure out the rest then maybe you've been drinking a 
little too much kool-aid.) But, switching map providers : that supposed to be bad 
"design",! guess. 



I did it on purpose to demonstrate that even if you used a tool like del.icio.us 



maps http://www.aaronland.info/www/deliciousmaps (or, say, the Yelp 
API http://blog.yelp.com/2007/08/the-yelp-api-is.html ) to find 
something you might use a separate application to actually make yourself a pirate 
map. Okay, the truth is you probably don't care one way or the other but just go with 
it. Imagine being able to link to a completely different pirate map tool simply by 
passing a location's latitude and longitude. That's the second image which, in turn, 
uses WS-modestmapS http://mike.teczno.com/notes/oakland-crime- 
maps/x . html to render the map view for that location. 
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The biggest problem with the pirate map generator is that it doesn't exist yet. 
But it would look something like the third image. The idea is to have a simple web 



application which displays a static map image with an SVG (or Canvas) overlay 
and controls to draw straight lines and text and move them 

around http: //a jaxian.com/archives/inputdraw-al low-drawing- in- forms 

Curves and colours would certainly be nice but seem like overkill right now since 
the goal is to produce something barely more complicated than the fourth image; 
this is what WS-raster http://aaronland.info/java/ws-raster/ does. Once 
the SVG layer has been serialized it can be sent off (in-situ if you want, using the 
magic of scrumjax http://www.w3.org/TR/XMLHttpRequest/ ) and converted in 
to a PNG file. Which, it's true, is kind of stupid in a web application. 

The point, though, is not necessarily to generate PNG files in the pirate map 
generator itself. Rather you want to "draw" the map once and then retrieve it later. 
For example, when you are aggregating a collection of places to create a printable 
guide http : / /www . aaronland . inf o/weblog/2 07/04/01 /thick/#paper f s . 
Some day this might happen in a web browser but right here, right now it's still 
going to happen in boring-old programming space using something like 
pmPDF http :/ /www. aaronland. inf o/weblog/2 007/ 04 /01/thick/#pmpdf 03 , 
which is written in PHP. That's what nice about these stupid HTTP wrappers: a 
POST request is the same in JavaScript as it is in PHP as it in Java and doubles as 
the glue between all three; I don't have to write another PDF generator in Java or an 
SVG converter in PHP or either in JavaScript. 

There is a second part in all of this left as an exercise to the reader : How and 
where you store the pirate map, whether it's an SVG file or a PNG image, in the 
interim? The glib answer is : Just put it on the Internet. The serious answer is : No 
really. Imagine that the place you've just drawn a map for has some sort of unique 
identifier even it is just its latitude and 

longitude http://geohash.org/9q8yyipxew0 . That's your identifier which can 
be turned in to a fragment in a URL or an attribute, on a file, that can be indexed. It 
becomes the glue that connects, say, a restaurant listing and a pirate map and a 
printed document (and then back again using tricks like 2D 
barcodes http: //www. aaronland. inf o/weblog/2007/02/17/platform/#wall ). 

We are fortunate to be working at a time when network-enabled services for 
storing blobs of data are readily available, easy to use from a variety of 
programming and application environments and dirt cheap. You can easily squirt 



either the image itself or SVG "source" in to a blogging platform, store on 
Amazon's S3 

Servers http://www.aaronland.info/weblog/2 007/12/2 0/castles/#zomg or 
abuse any of the various social sharing sites (which is bad form but I mention only 
as an example since people do it anyway) . For all anyone knows you could store the 
data locally on your hard drive and, using the magic of the file:// URL 
scheme http://toois.ietf.org/htmi/rfci738 , none of the other pieces in the 
process would be any wiser. 

Find, plot, identify, draw, store, retrieve, render, print, find. 

This is classic plumbing which means you still need to fasten all the pieces 
together yourself http://iaughingmeme.org/2008/02/28/2007-was-not-the- 
year-of-the-addressbook/ . As a consequence, people who aren't comfortable, or 
don't care, to work at this level are left standing on side muttering things like 
"dorks" under their breath. Another way of looking at that is to say when all there is 
are are just pipes and valves and connectors it means more people can stick more 
bits together in more different ways building more actual applications for more 
people, including the ones who don't care about the details. 

That, at least, is the goal. One small piece at a time : ws-raster 

0.1 http: //aaronland. info/ java/ws-r aster /ws-raster-0 . 1 . tar .gz 



2008-03-03T00:38:32-0800 



Rainbow extends Pony throws 
Unicorn 



I am a Java programmer. Sort of. I guess. There, I said it. 

I have my preferences, for sure, but I try not care too much about one 
programming language versus another. I was schooled by sysadmins and security 
weirdos and learned early on that all languages suck and you simply choose 
whichever one sucks the least for the task at hand. 

What I have developed a strong opinion about is documentation. And 
example code. Maybe the other way around. 

For all that people complain about Perl I have yet to see any other 
community as committed to and as diligent about 

documentation http://cpan.org/ . I've given up trying to understand why 
people are so resistent to Perl's Plain Old 

Documentation http://en.wikipedia.org/wiki/Plain_01d_Documentation 
format. I suppose some of the rules are confusing (in the same way that 10% of 
XPath is hard, while the other 90% is just useful) but it's always struck me as the 
perfect amount of structure and free-form. 



The structure is only there to ensure that the content can be translated in to a 
variety of formats with a measure of sanity while the content tells you what the code 
does, like two people having a conversation. Not as a clinical abstraction but in the 
developer's own words. 



Instead of clunky, artificial "these are the inputs, these are the outputs." 
Tell a story about what happens when the function is used. 



Michael Schwern, Documentation as 

Narrative http://schwern.org/-schwern/talks/What_Works/What_Works/slide058.html 



At this point the peanut gallery will tell you that they have to be so dedicated 
because there are so many ways to fuck Perl up. Personally, I'm okay with that. I 
will take actual code, with decent comments (read: documentation) , that fucks 
something up, where I can turn the knobs and add debugging statements over a 
black box of contracts and interfaces — inputs and outputs — every single time. It is 
not only the best way to learn the mechanics of a language but also the 
idiosyncracies that govern it. 

Example code is the view source of 

programming. http://www.tbray.org/ongoing/When/2 00x/2 003/05/21/RDFNet 

Anyway. That's just to say that I've never been predisposed to Java which 
has possibly the most thorough and thoroughly impossible documentation standards 
of any programming language today. Using 

JavaDoC http://java.sun.com/j2se/javadoc/writingdoccomments/ feels like 

being forced to memorize a high school yearbook (or more likely a college 
facebook heavy in achievements but devoid of any useful information like whether 
a person snores in bed or is a mean drunk) rather than actually making friends with 
anyone. 

Back during the job search before 

Flickr http://www.aaronland.info/weblog/2 04/10/22/5556/ I actually set 



aside a couple hours each day to learn the language and set out to faithfully read the 
canonical primers and Understand the Principles. See, this is the classic mistake 
number one but since there is no example code outside of Sun's own Hello World- 
grade documentation it's easy to trick yourself in to believing it's a worthwhile use 
of your time. I was going to at least tackle class 

paths http : / /www . panix . com/userdir s / j dw/ j avasucks . html which seem to 
exist only as some sort of stubborn chamber of "somber second thought" to the 
language itself preventing you from doing anything until you've satisfied a laundry 
list of demands, grounded more in ritual than any apparent need. 

Mostly what happened was that I started writing a book in my head titled 
"Everything You Need To Know About Java You Already Know In Perl". It 
seemed to me that both languages did pretty much exactly the same thing in mostly 
the same ways. Or put another way : There's more than one way to write Perl, and 
one of them happens to be Java. Because the literature that surrounds it is so strident 
and earnest in tone, never mentions the gotchas or explains the fiercely reductionist 
view that it takes to every operation Java mostly just seemed like, well. ..a waste of 
time. 






7V& 



I mean, if you're going to suffer through terrible documentation (the 
exception to the rule http : / /diveintopython . org/ , notwithstanding) then you 
might as well use Python since it's not nearly as mysterious in the theory and dogma 
that it levies against programmers. 



Which is kind of sad because Java has a lot of really great libraries for, you 
know, doing stuff. At least that's what I kept telling myself. Then, all of a sudden, I 
was living in Vancouver back up to my neck in 



PHP http://www.slideshare.net/royans/flickr-php wondering, like 
everyone else, just what the hell the order of arguments that you pass to any of the 
array http://us3.php.net/manual/en/ref.array.php functions is. 

[pause] 

I remember the first time I picked up a book of recipes by Elizabeth 
David http://en.wikipedia.org/wiki/Elizabeth_David . It was nothing but a 
collection of paragraphs. There were no ingredients lists or step by step instructions. 
Just the shapes of 

recipes http:/ /www. aaronland.info/weblog/2007/08/21/address/#doom , 
terrifying in their brevity. The point being that a "pinch of salt" is a little like the 
classic definition of obscenity : No one can tell what it is but everyone knows what 
it is when they see it. 

This is not to say, despite the popular belief and current interest in aerosol 
beef... I mean "molecular gastronomy", that computer programming is like 

COOking http : / /www . idlewords . com/ 2005/04 /dabbler s_and_blowhards . htm . 
Far from it. I mention the two together only to demonstrate that, while the two both 
tell you how to do something, the richness of story-telling the same 
recipe http://pieac.sourceforge.net/ should serve as a counter-weight to the 
programmer's tendency to problem solve (or document) by boiling the sky. 

Meanwhile — and I promise, this is the point — the Google/ Android kids 
went and wrote an open source 2D barcode decoder library, called 
zxing http://code.googie.eom/p/zxing/ . There are no shortage of 

encoders http:/ /www. aaronland.info/weblog/200 7/02/ 17 /platform/#barcode 
out there but the readers have always been mobile phone apps, libraries trapped in 

a twisty maze http://www.pedemonte.eu:81/pyqr/index.py/pyqrhome of C 

dependencies or ... written in Java http://dei.icio. us/straup/qr+java , 
where the usefulness of the code (can anything else actually render SVG files?) 
never seemed to outweigh the headache of classpaths compounded by the lack of a 
simple run_me application compounded again by Java's worldview that 
reallyLongFunctionNames are better than even the tersest documentation. 



I had more or less relegated zxing, written in Java of course, to the corner of 
my mind where projects go to never happen when I discovered that they'd also 
written a really simple web interface to decode 

barcodes http: // zxing. org/w/decode. jspx . 




So I finally learned Java (with the most excellent help of 

Tom http : / /www . tom-carden . co . uk/tag/ j ava/ and 

Dave http : / /davedavedave . net/ and 

Paul http://flickr.com/photos/bauwerkz/410311816/ who all Suffered my 

questions, badgering and whining graciously). 
If you do this : 



you § localhost in /home /yer /bin /ws -decode-0 . 1 

$>. /start. sh & 

ws-decode server running on port : 9955 

documentation and usage is available at http: //localhost : 9955/ 

you @ localhost in /home /yer /bin /ws -decode-0 . 1 
$> curl http://127. 0.0. 1:9955 



You get this : 



ws-decode is a bare-bones HTTP interface for decoding 2D barcodes. It works like 
this: 

You send a (binary) POST request to http: //localhost : 9955/decode containing a 
PNG or JPG file and the server will send back a plain-text version of its (the 
barcode in the image, of course) message body. 



rl -v -H 'Content-Type: image/jpeg' -H 'Expect: ' — data-binary \ 
' @ /Users /asc/Desktop/aa. jpg' http://127.0-0. 1: 9955/decode 



ct() to 127.0.0.1 port 9955 



* Trying 127.0.0.1... 

* connected 

* Connected to 127.0.0.1 (127.0.0.1) port 9955 
> POST /decode HTTP/ 1.1 

User-Agent: curl/7.13.1 (powerpc-apple-darwin8 . ) libcurl/7 . 13. 1 

OpenSSL/0.9.71 zlib/1.2.3 

Host: 127.0.0.1:9955 

Pragma: no-cache 

Accept: */* 

Content-Type: image/jpeg 

Content-Length: 4930 

< HTTP/ 1.1 200 OK 

< Date: Fri, 22 Feb 2008 06:50:39 GMT 

< Content-length: 28 

* Connection #0 to host 127.0.0.1 left intact 

* Closing connection #0 

http: //aaronland . inf o/weblog 
That's it. It will not make you a pony. No. No ponies for you. 

Which does even less than the zxing service, but that's by design. The 
design, as such, is modeled closely after everything I learned building and using ws- 
modestmaps http: //www. aaronland. inf o/weblog/2 008 /02/05/fox/#ws- 
modestmaps : 



• "Inline " documentation, for humans . 

• You can run it yourself, locally. If you want to expose it as a public- 
service on the Internet that's your business but I don't want to rely on 
someone else's uptime for all my tools. Plus, there's the privacy thing. 

• Just talk HTTP because it has won as the bridge between programming 
languages. Note, that I did not say talk REST or SOAP or WSDL or 
POX or JSON. Who cares which one you, or some other widget, talks? 
If you can't implement any one of those (okay, SOAP and WSDL are 
just stupid anyway so we'll leave those out for the moment) in a couple 
of hours you've got bigger problems. 

• As an aside, if anyone knows the guy who 

backported http://javabiog.co.uk/2007/10/27/http-server-api- 
backport-to-java-5/ Java 1.6's HTTP server 

API http: // java.sun.com/ javase/6/docs/ jre/api/net/httpserver/spe 

summary.html to Java 1 .5 please hug him for me. 

• Use GET whenever you can and POST only when you have to. The rest 
of it? Yeah, sure, we finally got working support for standards like 



CSS-2 http: //www.w3 .org/TR/REC-css2/ six years after they were 
finalized and we 're all the richer for it, now, and maybe some day the 
entire suite of HTTP verbs will be implemented across a wide range of 
... anything other than [insert your programming language here]. Wake 
me up when the barcode reader on my phone can PUT a file 
somewhere. In the meantime, everything supports GET. And I can 
debug stuff in a web browser. 

Be self-contained and do not require anything more to start than a 
single command line application. Asking me where my "jar files" are 
located defeats the whole point of having jar files. This is why God 
invented shell scripts. Serioulsy, half my time writing ws-decode was 
spent trying to figure out how to package and wrap things so that it 
would Just Work out of the box. I guess the good news is that I can use 
all that pain as a cookie-cutter approach for whatever comes next. 

Do not boil the sky. My decoder app is little more than an HTTP 
wrapper around zxing's decode 

function http: // zxing.googlecode.com/svn/trunk/javase/src /com/goo 

It does nothing else, nor should it. This is not an attempt to provide an 
all-knowing, magic, dancing "cloud" interface to Java libraries from, 
say, Perl. It's just the quickest way to export small pieces of 
functionality loosely joined across the Internet, whether that happens to 
be on the same computer, the same room or across the Network. 
Net::Flickr::Geo http://search.cpan.org/dist/Net-Flickr-Geo 
is written in Perl because I can't deal with any of the other language- 
specific bindings for the Flickr 

API http://www.flickr.com/services/api/ but I'm also not about 
to rewrite all of ModestMaps http://www.modestmaps.com/ in Perl 
so the two just talk to each other using ws- 

pinwin http://modestmaps.com/examples-python-ws/ .Simple. 

Not a "framework". 



And now there's another little piece of the 
Papernet http://www.aaronland.info/papernet/ that has been built. Which is 



the important part. 




No, I will not add a barcode for this link here : ws-decode 

0.1 http: //aaronland.info/ java/ws-decode/ws-decode-0 . 1 .tar .gz 



2008-02-04T22:55:35-0800 



A short history of ws-modestmaps 



This is the story I want to remember. 

The first time I heard about the command line interface in 
ModestMapS http : / /www . modestmaps . com/ was at the bar. 
Mike http : / /mike . teczno . com/ and I had foolishly agreed to meet and talk 
while I tried to watch the hockey game. 

A few months later I sat, drinking coffee, ripping out the near-complete 
Turing machine that had taken root in the command line application's options 
parser. 

I love slippy 

maps http://wiki.openstreetmap.org/index.php/Slippy_Map as much as the 
next person but my name is Aaron and I have a paper 

fetis http: //www.nscad.ns . ca/ showcases /f acuity .php? 

leftmenu=l&memberID=30scollectionID=24 A H A H A H I mean, I hate the Internet. 
At least the web. And probably electricity. Or, put another way, I haven't really had 
any new ideas in the last year and am still worming my way through the boring 
details that grow like barnacles on the side of the 

Papemet http://aaronland.info/papernet/ . 
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Anyway, eventually Mike and I went for beers again and I explained that I 
had written a small HTTP-based wrapper around the command 

line http: //modestmaps .maps tract ion . com/ trac /browser /trunk/py /compose. py 

application so that I could call it easily from the code that generates the 

PocketMod http:/ /www. aaronland.info/weblog/2 007/07/28/trees/#mmpdf_03 

books I'd been working on. 
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It didn't do much more than that, and even then didn't expose the command 
line version's complete interface. All it could was render a map centered on a 



latitude and longitude and optionally paste a 75x75 pixel PNG image of a pinwin, 
with a zoomed in version of the map pasted in to its canvas. 

So, was born ws- 

COmpOSe.py http: / /modes tmaps .mapstraction.com/trac/browser/trunk/py/ws- 
compose.py?rev=339 

Soon afterward, I added ws-compose support to the 
mmPDF.php http: //www. aaronland.info/weblog/2007/07/28/trees/#delmaps 
class in time to print a handy booklet of coffee shops and restaurants in Victoria, for 

FOSS4G http://www.flickr.com/photos/straup/sets/72157 602 215917514/ . 

Showing it around the conference we all agreed that it still suffered the fundamental 
problem with these things : That web-based tiles + consumer-grade printers = shitty 
maps. 




For a long time I've been threatening to build some sort of JavaScript-y 
"pirate map" generator. Specifically, overlay an SVG (or Canvas) canvas on top of a 
static map or even a proper slippy map with a limited set of drawing controls to 
trace only the streets and landmarks that you care about. 



Yes, like the stripped down idealized directions maps that came out of 
Microsoft Labs a few years ago. The one whose address on the Interweb I can never 
find. Exactly like that. 




There are still a few problems with this approach. The first is that there is no 
magic for including street names with their corresponding strokes in the SVG layer. 
Finding time to feel the Open Street Maps http://www.openstreetmap.org/ 
(OSM) luv is the most elegant solution to this problem, by writing a simplified 
interface to select only those features you want included in a map. Since each 
features "knows" what it is it's pretty easy to include that metadata — the street 
name — with the final map. Where pretty easy means no one has built that sort of 
stripped-down web interface for OSM but there you go; there shouldn't be anything 
preventing someone from doing it beyond time and quirks-mode. 



The brute-force approach to the problem, suggested by 

Schuyler http://mappinghacks.com/2008/02/14/free-map-india-2008/#more- 

163 , would be to call the especially clever Google reverse geocoding/directions 

hack http : / /nicogoeminne . googlepages . com/documentation . html#Reverse_Geoc 

using any point on a selected road as the input. This is as brittle as it is brutish and 
prone to all kinds of errors, failures and unexpected results but it's still a nice 
example of treating APIs as being like the nubby bits on individual pieces of Lego. 




The second problem is where you actually store the newly created pirate 
maps so that they can be used by tools like mmPDF or ModestMaps. The clever 
solution would be to use Jordan Sissel's "filesystem driver" for storing real files 

in del.iciO.US http: //www. semicomplete.com/blog/geekery/yahoo-hackday-06- 

parti . html but that the hooks that allowed the hack to work have since been 
disabled. My hunch is that the Right Way to deal with the problem is squirt the data 
in to FeatureServer http://featureserver.org/ and then add a ModestMaps 
provider which will fetch and render the data without an underlying tile layer. 
Quick, look at my waving hands and you won't notice all the parts I haven't 
considered. But I think that would work. 

Meanwhile, Mike went and wrote a pure-Python implementation of Bill 
Atkinson's dithering 

algorithm http://mike.teczno.com/notes/atkinson.html . This was 
especially useful because if you dither a map rendered with standard road tiles, even 
at small sizes like 300 pixels, you end up with something surprisingly. ..legible. A 
bit ugly but that's largely made up for by street names you can read and the collosal 
amount of hoop-jumping needed to do anything else. Plus, dithered aerial tiles are 
hawt. They make old-skool cities like Paris and London with their not-so- invisible 
hand of god urban layouts shine and save newer, North American, cities from 
looking like the grid of plasticine pegs that they sadly are. 

But I digress. 



The Python bindings for ModestMaps have always let you render two kinds 
of maps : one centered on a point spiraling outwards to fill a fixed height and width, 
the other that zooms out until it can fit the extent of a bounding box inside a fixed 



height and width. 

That set the stage for the long slog towards what began as "ws- 
kitchensink.py" and was finally released as ws- 

pinwin.py http: //modestmaps .mapstraction.com/svn/trunk/py/ws- 

pinwin . py .1 wanted a map where I could specify a bounding box and zoom level 
(as a rule, street level) and just say : Tile it, size be damned! 

For lack of any better name, I called these "poster 

maps http://flickr.com/photos/mbiddulph/2250018495/ " 




And pinwins. All kinds of pin wins. Pinwins with different sizes. Pin wins 
that don't overlap. Pinwins with automagic shadows. Pick two. 



The order of events was roughly : Mike holding my hand to work out adding 
multiple markers (pinwins) to a map, followed by me trying to be smart about 
calculating the criteria for giant maps and then giving in and using the 

JDFI http : / /www. per If oundation . org/per 15 /index . cgi? j f di solution. The 

code to generate the actual markers was pretty simply but tedious and it's still not 



even clear to me what the distinction between a marker and mrk_data is. 
Something like the latter needs to know about the former but not the other way 
around but the truth is that it's all still a twisty maze of variables used to juggle 
offsets, and differing coordinate systems, made even yet more complicated by the 
part where I can't make heads or tails of the 

PIL http://www.pythonware.com/products/pil/ documentation for paths SO 

the markers are nothing more than a bunch of primitives glued together with 
bubblegum and spray-painted white. 

But, really, who cares because now you can do : 



&marker=mileend, 45. 525825499457, -7 3. 5989034175872, 6 00, 180 \ 
&marker=roy, 45. 52137 5561025756, -7 3. 57 049345970154 \ 
&marker=cherrier, 45. 5197 8191639917, -7 3. 56947422027588 



And get back : 



HTTP/1. x 200 OK 

Server: BaseHTTP/0.3 Python/2.5 

Date: Sun, 13 Jan 2008 01:08:37 GMT 

Content-Type: image/png 

Content-Length: 1946576 

x-wscompose-Image-Height : 1024 

x-wscompose-Image-width: 1024 

x-wscompose-Map-zoom: 14.0 

x-wscompose-Marker-mileend: 336, 211, 157, -131, 600, 180 

x-wscompose-Marker-roy: 667, 285, 629, 165, 75, 75 

x-wscompose-Marker-cherrier : 679, 312, 641, 192, 75, 75 



I care a little but mostly because the anchors — or the cones — for the 
markers aren't anti-aliased so it's on the list to try to check whether the Cario 
graphics libraries are present and use those 

instead http://cairographics.org/cookbook/roundedrectangles/ . I mention 

that because as attractive as it is to do the Right Thing and find the Beautiful Truth 
in math sorting out the shadows, and later re -positioning, for the pinwins reminded 
me that the "wrong" way was actually better. 

def mkperspectiveshadow (self) : 

# 

# I R DUHM . . . why won ' t someone explain to me the math behind : 
# 

# http: //www. eye loloco.com/shadowmaker/ 

# http: //www. ess .taylor.edu/-btoll/s99/424/res/mtu/Notes/geometry/geo-tran.htm 

# inkscape's extensions/perspective .py 
# 

# so that I can do this : 
# 

# im.transform(size, PERSPECTIVE, data) 
# 




I say "Math is hard" a lot, and mostly mean it. 

I spent a lot of time badgering my friend 
Prasun http://fiickr.com/photos/straup/42445i875/ , who is a computer- 
vision wonk, to explain how the eight values you need to do a persective 

transformation are derived http: //raumkraut.net/libs/perspective . I 

managed to dig up lots of almost-solutions but nothing to do proper Google Maps 

Style Shadows http://www.cycloloco.com/shadowmaker/ on the fly. 

"Real http://aaronland.net/artboy/room/ " shadows and all that. 



Prasun never did explain the Math Shapes to me but instead pointed out that 
since the vantage point of the light source (casting the shadow) is always the same it 
was probably easier to just do some sloppy math once and apply that single 



transformation uniformly to every marker. Which is true but made more 
complicated by having to spoof the perspective on the rounded corners. At least the 
fact that the shadows are semi-opaque and, typically, sitting on top of a background 
image means you can rely on the human eye to compensate (read: not notice) some 
of the quirks that remain. 

Still. There is no math here. Only shapes ballparked relative to the size of the 
marker itself and duct tape. 

The next step was to try and figure out how to deal with markers clustered 
near and overlapping one another. This is some sort of classic design/visualization 
problem, I guess, but I quickly decided that just exploding all the markers out 
from their anchor 

point http://www.aaronland.info/weblog/2 007/12/2 0/castles/#rocks 
would acheive nothing more than covering the surface of the map in pin wins. 

The alternative — a rain-drop style layout like the one shown on the right — 
is not entirely satisfying because simply stacking nearby markers along the y-axis 
makes for ridiculously large images. Ridiculously large quickly becomes out-of- 
memory and bus errors when you render a large bounding box at street level (the 
Center of Paris http://flickr.com/places/France/Ile-de-France/Paris out 

to, say, Charles de Gaulle 

airport http://flickr.com/photos/tags/aero:port=cdg ) but it also proves 

that true to life shadows for markers with lengthened markers only serve to distract 
from the final image. 

This was also around the time when I realized that I would have to add an 
option to "bleed" an image, to adjust its final height and width to ensure that any 
markers wouldn't be cropped by the dimensions of the map tiles. I've been asked to 
add the option to fill in the bleed space with more map tiles (on the list) but I 
happen to like the white space adding a kind of anti-perspective to the whole thing. 
It's also pretty obvious, then, that the shadows are waging their private war on 
perspective shooting up in to space only to flop down, suddenly, when they reach 
the marker canvas. 




On the other hand, since the markers have no outline of their own the 
misplaced shadow serves to outline just enough of the shape to tell you what's going 
on without too much distraction. I can't imagine realistic shadows spreading out 
across the bleed space like zebra stripes as anything but annoying. And ugly. 

The pursuit of a faithful representation is laudable enough but, frankly, save 
it for your ray-tracer. We're talking about maps, 

here, http: / /www. slideshare.net/blackbeltj ones /designing-f or-spacetime- 
ixda0 8 



Sooner still I would like to add the hooks to pivot a marker canvas ninety 
degrees so that a very tall image could in fact be printed as a very long image. Long 
is useful because it means you could print and zebra-fold the whole thing in to a 
book. Or tile the final image again and print them out as individual pieces on ... say 
postcards http://moo.com/products/postcards.php and stitch them back in to 



something entirely new. 

And yes, of course, re-tiling images back in to "plain old" map tiles. Oh 
yes... 

For starters, though, there is only the obligatory Flickr 

hack http: //www. aaronland.inf o/weblog/2007/06/08/pynchonite/#net- 

f lickr-geo . Though more or less functionally complete, near or before a final 
"release" I wanted to update Net::Flickr::Geo.pm to play nicely with ws- 
modestmaps http : / /search . cpan . org/dist/Net-Flickr- 
Geo/iib/Net/Fiickr/Geo/ModestMaps .pm and then some. Besides the grunt work 
of building custom markers (ws-pinwin does not handle compositing an image in to 
a marker's canvas) you can now ask it to fetch all the geotagged photos for a set, 
plot its bounding box and generate a "poster" map. For extra points you can also ask 
it to chop the final image in to 4 x 6 sized pieces and have the whole bloody thing 
re-uploaded to Flickr. 

Some day, the nice printing services will have public-facing APIs. 

All the pieces of ws-modestmaps are checked in to the ModestMaps source 

tree http: //modes tmaps.mapstraction.com/trac/wiki/SubversionAccess and 

there's even a real tutorial with working sample 

Code http: //modestmaps .com/examples-python-ws/ . There's also support for 

rendering arbitrary polylines coming soon but it's time to let this one lie down and 
have a rest for a while. 

I'm sure I've forgotten some tiny and important anecdote (more likely, just 
spelling mistakes) but I feel like I've been working on this post for as long as I have 
the code — hello cow orkers, I will come in to the office soon, I promise — so I'll 
just leave it at : Patches are welcome. 




Oh, and, pinwins large enough to fit moo.com 
stickers http://moo.com/products/stickers.php need to be 126 pixels square. 
I'm just saying... 
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Things I Went Home To Talk About 

Talk To the Hands 



Talk To the Hands 



21:23:36 A: trying to work up the energy to write a thoughtful (hahahaha) 
blog post about talk-talk-talking in montreal 

21:25:16 M: knowing you it will be interestingly disjointed and full of 
allusions =) 

21:26:06 A: "a covert indication" 

21:26:14 M: hehehe 

21:26:20 A: that is a better blog title than "talk to the hands" 

21:26:34 A: http://flickr.com/photos/videopresse/2397628046/ 

21:26:53 M: ha nice hand modeling 

21:27:29 A: "in this hand I hold an API" 

21:27:36 A: "with this hand I will poke it" 

21:27:43 M: *poink* 



It turns out that I do some weird-ass shit with my hands when I speak 
publicly. 

Back in December I mentioned that a couple of proposals I had submitted 
for conferences had been turned 

down http://www.aaronland.info/weblog/2 007/12/12/things/#talk-is- 
cheap . As it turns out, one of the two "rejections" was really just a prolonged 
series of false starts and lost email messages and, in the end, I had the opportunity to 
give both presentations while I was in Montreal, at the beginning of the month. 

Originally, the plan was simply to attend Museums and the 
Web http://www.archimuse.com/mw2 00 8/ with George following the launch of 
The Commons project on Flickr http://www.fiickr.com/commons/ and serve 

as her technical wife http://flickr.com/photos/straup/2328347447/in/set- 

72157604100661498/ should the need arise . Museums and the Web was held in 
San Francisco last year http : / /www . archimuse . com/mw2 007/ and I managed 
make it down for a short afternoon before some crisis or another at work sucked me 
back in to the office so once I got over the initial sting of thinking the conference 
organizers didn't care what I had to say I was pretty excited about attending. Since 
the last game of the (hockey) 

Season http://www.flickr.com/photos/tags/canadiens was only a few short 
days before I went home early to be with 

friends http://flickr.com/photos/straup/2398588206/in/set- 
72157604522954775/ . 



Normally when I work from Montreal it ends up being a mix of time spent 
between Laika http://www.fiickr.com/photos/bopuc/277427599/ ,the 

"BoLab http://www.flickr.com/photos/bopuc/577389036/ " and the floor of 

wherever I am staying. Which is not unlike what Patrick http: //i. never. nu 
used to do but in the time since my last 

visit http://www.flickr.com/photos/straup/sets/72157600484834830/ he 
(and Daniel Mireault) took the idea for a co- working space, in Montreal, from 
hand-waving over 

COffee http://www.flickr.com/photos/straup/6247253 02/in/set- 

72157600484834830/ and turned it in to a living , breathing space called Station 
C http : / /www . station-c . com/ . It goes without saying that I signed up to work 
from there for the few days I had before the conference. 

Patrick invited me to do a casual, 5 a 7 style, presentation one night on 
whatever I felt like suggesting maybe the work that I had been doing with 
ModestMaps http : / /www . modestmaps . com/ . I chose to spin it out a little further 
and do a rough survey of all the work that had been done since the original 
Papernet talk at XTech, in 

2007 http://www.aaronland.info/talks/papernet/ . This had the advantage of 
being sort of like the original "Computational Deepwater" proposal without any of 
the stress of having to find a capital-P "point". It could just be a fun romp through 
all the sprockets and widgets that I've tinkered with over coffee in the mornings, 
trying to tease an idea whose shape is still unclear to this day. 

Earlier in the year, a few people asked me if I had submitted anything to 
XTech this year. Putting together the slides for the Station C 

talk http: //station-c . com/ e vent s/aarons -paper net-at- the- station/ was 

instructive since my answer had always been a foot- shuffling and sheepish "No". 
Maybe I was just feeling shy about getting turned down again but, at the time, it 
didn't seem like I had anything "new" to talk about. It was all just the same old thing 
I'd stammered on — and waved my hands around — about a year earlier. 

Which was really dumb since As Cheathco Says http : //anti- 
mega, com/antimega/ : The learning is in the making. In the end, I had a 
wonderful time doing the presentation, people seemed to enjoy it and it offered me a 



chance to look back at the last year in some perspective. There's maybe not a lot of 
"new" for anyone who's been reading this weblog for any amount of time but at 
least there are some pretty slides... 
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Apropos of nothing, between everything he has done at Station C and 
YULblog http : / /www . yulblog . org before that I'd like to nominate Patrick for 
an annual Just Fucking Do It 

Award http://fiickr.com/photos/biackbeitjones/2592/ for at least the next 
six or seven years to come. 

Then, the next day, I went back to some of the most mind-crushingly boring 
work I've had to do in the last five or six years and forgot to take an "I'm on a 
telco! http://flickr.com/photos/straup/436573217 " picture as I walked 
down the Main, on my way to lunch, talking to people in far-away offices. 

Meanwhile. 

Sometime before the liquid supercollider better known as 

SXSW http://www.flickr.com/photos/straup/sets/72157604100661498/ , I 

received an email from Jennifer 

Trant http://conference.archimuse.com/blogs/jtrant/ asking if I had been 
able to tease anything more than covert indications out of my original proposal for 
Museums and the Web. This was always a reasonable request and Jennifer, who I 
first met at 

WWW2006 http://flickr.com/photos/straup/sets/721575941455466 84/ 
where she did a presentation on stevcmuseum 

project http : / /www . steve . museum/ , proved to be nothing but reasonable and 
doubly-patient trying to coax little more than excited hand-waving into something 
she could stand to include in the conference proceedings. 

If you're curious, the first reply I had sent trying to make sense of my 
original proposal had gotten lost in the email- spam vortex and the perceived silence 
on both sides of the confusion led me to feel shunned and, in turn, probably just 
seem like a flake. Jennifer is a rock star for reaching out and forcing me to collect 
my thoughts and write something that pretends (tries to pretend?) to be a proper 
paper on 

TV http://www.archimuse.com/mw2008/abstracts/prg_335001679.html . 



The short version is that I stood in front a room full of museum people and 
said : You need to teach computer programming in art schools and hire full-time, in- 
house technical/development teams even if it's a single person. The long version 
involved me telling them that all the magic talk about embracing the web without 
those people, which really means the skills, was pretty much idle and meaningless; 
sorry to be the Bad Man. 

If only I'd know about 

this http: //www. lifeonashirt.com/2008/04/22/there-are-just-some-things- 

you-cant-taik-about/ when I was giving the example that Threadless is 
printmaking http://www.threadiess.com/ by any other name... 

All in all, a pretty cheeky recap because what I really wanted to impress on 
people was not that everyone has to become a computer nerd but that programming 
is just another tool to shape an idea. The same way we teach printmakers to dance 
with tubs of acid and show photographers to find the magic in something as 
mundane and technical as developing film we need to discover the mystery and 
possibility available by (not goatse, no don't say it) diving in to the plumbing of 
the web http://biogs.waikerart.org/newmedia/2008/04/10/mw2008- 

theoretical-frameworks/ , SO to speak. 



"She gestured for the living room, phasing past what would've 
been the door to her mother's bedroom. She'd barely wireframed 
it, here, and there was no there there, no inferiority. The living 
room had its sketchy angles as well, and furniture she'd imported 
from a Playmobil system that predated her Sandbenders. 



illiam Gibs 



"Wonkily bit-mapped fish swam past monotonously around in a 
glass coffee table she'd built when she was nine. The trees 
through the front window were older still : perfectly cylindrical 
Crayola brown trunks, each supporting an acid-green cotton ball 
of undifferentiated foliage. If she looked at the tree long enough, 
the Mumphalumphagus would appear outside, wanting to play, so 
she didn't." 
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Some day a security guard will tell you to "stand 
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Oh, and it also means museums can move away from the six-month, one 
hundred and eighty thousand dollar deploy cycle any time they want to try 
something on the web. Which has to be a good thing. Just look at the Powerhouse, 

in Sydney! http://www.powerhousemuseum.com/dmsblog/ 

I think it went well and the nerds in the crowd seemed pleased to have 
someone stand up and sound the trumpets. It remains a hard problem, though, and 
one that is compounded by the scarcity of funds in the arts community so everyone 
will come at it differently but it is a necessary — and worthwhile — problem to sort 
out. 

One pretty awesome moment for me was being up on stage and being asked 
the brass tacks "How do we actually teach this stuff to art students?" question and 
seeing two women at the back of the room — Kara Pajewski and Lauren 

Addario http://www.flickr.eom/photos/22 065710@N06/sets/7215 7 6045 8698123i 

students at the New Mexico Highlands University — jumping up and down saying : 
It's already happening and we're doing it! I learned later that another student 
attending the conference, Jonathan Lee, was responsible for much of programming 
work on the American Image: The Photographs of John Collier 

Jr. http: //www. archimuse.com/mw2 00 7/abstracts/prg_325 00 11 00. html 

project. 

Hats off to Miriam 

Langer http : //www. nmhu . edu/f acultystaff /directory /eddepartment list . htm^ 

deptid=2i&Category=C0MM,DES,MART , chair of the Communications and Fine Arts 
department at the University, for that. Yay! 

Update, see also : Mia Ridge's Talking to IT students about the cultural 
heritage sector, and a small 

'wOOt' http: //openobjects .blogspot.com/2008/04/talking-to-it-students- 
about-cultural.html . 

Something else that bubbled up talking to people at and about the conference 



is that, casting a wide and sloppy net, people in the arts and programming have no 
good way of communicating with each other. It's not that they don't respect and 
value the expertise of the "other" — they do — but rather they simply have no idea 
what each other are saying. Not even a little bit which makes it all the more difficult 
for people of like spirits, if not minds, to find each other. 

Short of fairy-tale uber-renaissance-pedants, who exist only in movies and 
people's resumes, no one has the capacity to keep up the minutiae of someone else's 
speciality but that shouldn't be a reason to actively avoid one another. After all, we 
all pretty much get drunk the same way regardless of what we "do" . 




Which is about as far as I've gotten with that one, really. How do you cut 
another person enough slack to feel like they can participate when you're 
dealing with something that you care passionately 

about? http: //george08 .blogspot.com/2008/04/disambiguity.html 



Otherwise, a bloody lovely time and the opportunity to meet a whole new 
Cabal of Friends. 



A good trip, http://www.slideshare.net/tag/mw2 008 
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We do it for the war stories, right? 
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For a variety of reasons I've been using my 

N810 http://flickr.com/photos/straup/2089499192 again, flashing the 

operating system and reinstalling stuff from scratch. The N810 does not make the 
Earth move, especially in a world of jail-broken iPhones. Its wireless chip is not 
terrifically strong, the GPS chip takes forever to establish a signal and the touch 
screen — let's be honest — makes you pine for Apple. 

But it is a pretty reliable workhorse of a device if you approach it with a 
measure of tolerance (compassion?) and — especially in a world of jail-broken 
iPhones — there is an impressive wealth of software already written and/or ported 
to run with little hassle. 

Which really means that installing anything not already in the "application 
manager" or with a handy "click to install" button on the maemo.org download 

pages http://maemo.org/downloads/product/OS2 008 is also mostly a pain in 

the ass but to be fair this is more a by-product of the LinuxIDebian community than 
it is any individual architecture astronauts at Nokia. Thank god for J org 
Gronmayer, who maintains a searchable index of all the various packages and 
"repositories " that you need to configure to 

install http://www.gronmayer.com/it/index.php anything. 



The N8 10's operating system (Maemo http : / /maemo . org/ ) is pure open 
source as is 99% (100?) of the software that runs on it. I have no beef with 
commercial software or developers but that something like Maemo came out of an 



environment that otherwise embraces stuff like Symbian's security 

model http://gagravarr.livejournal.com/134934.html is impressive and 

refreshing and deserves to be 

encouraged http://money.cnn.com/gaiieries/2008/fortune/0805/gaiiery.An_: 

Just for kicks a few months ago I pulled down a copy of 
ModestMaps http : //www.modestmaps . com from trunk, no less, using 

Subversion http: / /www. gronmayer.com/it /index. php? 

Iang=en&system=maemo4&sort=hits&show_pck=126#126 and wouldn't you know 
it WS-COmpose.py http: //www. aaronland.inf o/weblog/2 08/02 /05/f ox/#ws- 
modestmaps ran out of the box. Just like that. It blew its brains out trying to do 
Atkinson filtering http : //mike . teczno . com/notes /arduino-atkinson . html 
but otherwise generating maps and 

pinwins http://www.modestmaps.com/examples-python-ws/ Just Worked ! 

Anyway, imagine my surprise when I discovered that someone had actually 
gone to the trouble of porting ImageMagick, of all things, to run on the 

N810 http://maemo.org/downloads/product/OS2008/imagemagick/ . Which 

got me wondering : Would 

filtr http://www.aaronland.info/weblog/2 006/07/31/baconmelon/#£iltr run 
under Maemo? At its core it is just a glorified shell script that calls a whole bunch 
of other command line utlities. It took a little bit of wrangling on a Saturday 
afternoon to satisfy all the dependencie but, lo, it works! 

Setting it up is a bit of a chore so here is a step-by-step guide : 

1 . Install the OpenSSH 

packages http: //www. gronmayer.com/ it /index. php? 
lang=en&system=maemo4&sort=hits&show_pck=126#126 that come 

(listed in the application manager) with the N810 by default, or at least 
by default with the most recent OS update. 

2. Install the gainroot 

"application" http : / /ma e mo . org/community/wiki/HowToEASILYD e com e : 

It's just easier and faster than the alternatives. 



Actually, I am less convinced that gainroot — or the "root shell" 
at all — is even useful. Everything in Maemo is wrapped in the 
iron hug of sudo http://www.gratisoft.us/sudo/ so you are 
probably better off just logging in (via ssh) as root once (yes, root) and 
adding the ability to su up to root to the letclsudoersfile. At that point, 
go ahead and update your sshd_config file to disallow logins as root, if 
that creeps you out (it should). 

The only caveat if you do disable root login is that you will hold 
yourself at gun point every time you edit the letclsudoersfile. If you are 
sloppy, like me, and make a mistake your N810 will continue to work in 
its current state but "little things " like the application manager will be 
permanently hosed until you reflash the device (because sudo will stop 
working and logging in as root, in order to fix its configfile, is 
disabled) . 

This is the Unix permissions model doing exactly what it was designed 
to do, by the way. Given that there is no other way to log in to the 
device as root — say, some obscure (but documented, please) keyboard 
dance that could be performed at startup (but not without first checking 
that the default root password had been reset) — then you're left with 
one of two bad choices : do exactly what I did (or just disable root 
login 

altogether http: //maemo.org/community/wiki/HowDoiBecomeRoot/#4 5 08i 

and hope for the best or just leave root logins enabled. And hope for 
the best. 

All things considered, I prefer the latter. I had previously written 
something about making the sshd_config file writable by the default 
user but, with a moment's reflection, that proved to be little more than 
window dressing : You can edit the file to your heart's content but 
without the ability to restart sshd (which requires that you are root 
after all) it's pretty much moot. It's true that you could just restart the 
device in order to reflect the changes but assuming that you've chosen 
decent passwords , the ability to log in doesn't really give a person 
much but it is does provide a way for you to stop stabbing yourself in 
the face. You also won't give every other application running as user 
"user" the ability to silently modify your sshd _config file . 

So, with all that in mind, moving right along... 



3. Install the 

wifiinfo http://maemo.org/downloads/product/OS2008/wifiinfo/ 
application so you can figure out what your IP address is. That's right, 
the NS10 has no ifconfig command, if con fig is also available 
but it won't be in your default PATH so choose your 

poison... http : / /andrew . daviel . org/N8 10-FAQ . html#wif iinf o 

4. Install Python http://pymaemo.garage.maemo.org/ which is a 

total nuisance but basically involves ssh-ing to your N810 as root (see 
above) and then following the 

instructions http : / /pymaemo . garage . maemo . org/ installation . html . 

For whatever reason there is no standard "package" for Python even 
though all you end up doing is typing to commands in a shell. Once you 
get over the bad taste in your mouth it's pretty straightforward. 

5. While you're there you might as well install the Python GPS bindings, 
since they don't come built-in and you're going to be running apt-get, 

anyway http: //www. gossamer- 
threads .com/lists/maemo/developers/34884?page=last . 

6. Install 

ImageMagick http://maemo.org/downloads/product/OS2008/imagemagii 

If you've ever had to do this before you will perhaps find some cold 
comfort knowing that this is actually the easiest part of the process. 

7. Finally, pull down the most recent version of 

filtr http://aaronland.info/bin/filtr/filtr-0. 3. tar. gz or at 
least version 0.3 and higher, filtr is just a shell script and it tries to be 
smart about knowing where the things it needs to run are located so 
you should be able to simply uncompress the package and run it as-is. 

The big difference between versions 0.23 and 0.3 is that two of the 
dependencies, written in C, have been replaced with Python versions. Specifically : 
jhead http://www.sentex.net/-mwandei/jhead/ has been replaced by a short 
script that uses Gheorghe Milas' jpeg.py http://www.emiias.com/jpeg/ to 
move EXIF data from the source file to the filtr-ed version and 



md5sum http://en.wikipedia.org/wiki/Md5sum with Nick Craig-Wood's 
port http: //mail. python.org/pipermail/python-list/2005- 
February/30675 8.html . 

This probably means that filtr itself will be that much slower but, really, who 
cares and it means that the program will run on more hardware than I have the time 
or energy to suffer compiling jhead for. Despite the glorious madness of tools like 

PAMP http : / /wiki . opensource . nokia . com/pro j ects /PAMP : PHP_S 6 0_API (or 
a PHP port for Maemo http://www.gronmayer.com/it/index.php? 
Iang=en&system=maemo4&sort=hits&show_pck=124#124 ) Python continues to be 
the thing that finds its way http://aaronland.info/talks/soap/ on to just 
about every computer, large or small. This probably also means that version 0.31 
will check for the faster C applications and then fall back to the Python ones. 




That is all. It's not particularly fast, by any means. But it works and that is 
good and it opens up some interesting possibilities. For example, if I installed the 
py-inotify http: //pyinotify. sourceforge.net/ libraries (I just did) I could 
send via Bluetooth or whatever a day's worth of (geotagged) 

photos http://www.aaronland.info/weblog/2 008/04/30/warstories/#firedoppl 
to a special directory before going to bed. That would trigger a process to filtr the 
photos, plot them on a map with ws- 

pinwin http://flickr.com/photos/straup/tags/modestmaps and then use the 
Moo API http://www.moo.com/api/ to generate postcards. Then wake up in the 
morning to complete the process (read : enter my credit card number). I'm not 



actually sure that poor little Python could do all of that under Maemo without 
completing melting down but, done with a little care and hand-holding, it's 
definitely possible. 

Or something like that. Meanwhile : filtr 

0.3 http: //aaronland.info/bin/f iltr/f iltr-0.3 .tar .gz 
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FireDopplGangEaglr 



See also : Dan's Twitter API updates, FireEagle and new Flickr API fun 

http: //geobloggers . com/ archives /2 008/04/2 9 / twitter- api-updates- 

f ireeagie-and-new-f lickr-api-fun/ for a variation on the theme and a little 
more detail on some of the Flickr API methods mentioned below. 

First, there was "filtr" but that's another story 

entirely http:/ /www. aaronland.info/weblog/2006/07/31/baconmelon/#filtr . 
The point being that I gave up carrying around a capital-C camera a few years ago 
choosing instead to make do with cameraphones and the availability of cheap, 
unlimited data-plans in the U.S. 

I am mostly lazy and can't really be bothered to shuttle photos around from 
one device to another only to move them again to the giant device in the sky called 
Flickr. Before filtr I relied on the upload by 

email http://flickr.com/account/uploadbyemail/?from=email feature to 

snag a photo and quickly share it with the future-past but the desire to touch up — 
or filter — the photos before upload meant that I needed to write my own service to 
accept, process and then finally upload pictures to Flickr using the 

API http://www.flickr.com/services/api/upload.api.html . 




Which is what I want to talk about. Sort of. 

The advantage of an intermediary 

service http://rcrowiey.org/2007/12/30/postfixing-your-emaii-iife/ is 
that you can configure it to use the photographs it receives as triggers for other 
services. In my case this has always meant tags and geotags. Sometimes it is easy : 
It's pretty clear that I can tag anything that comes through with cameraphone. 
Sometimes it is possible : I can query a photo's EXIF data for a model number and 
assign an appropriate machinetag, say ph : camera=n82 . Other times, it's just 
plain wrong or so not right enough as to be useless : If I hardcode the tag " san 
f rancisco" for all my uploads it will probably be right unless I happen to go out 
of town for the weekend or otherwise forget to update the tools. 

Remember: Mostly lazy. 

Applications like 

ZoneTag http : / /www . plasticbag . or g/ archives /2006/10/ geotaggingwithzone 

and Shozu http : / /www . shozu . com/ have always had the ability to geotag your 
photos using a combination of GPS data and surrounding cell tower data. ZoneTag 
even tries to learn what tags are likely to "map" to a given spot but since neither 
application have any way to let me massage the actual photo they've never really fit 
the bill. 

For a short time, I tried to use del.icio.us http://dei.icio.us as a 
datastore for frequently photographed places. For example, if I took a photo of 
something posted to the Wall of 

Rant http://www.flickr.com/photos/straup/sets/72157 600018101230/ , in 

San Francisco's Mission District, I could add some magic text to the photo that 
would tell my intermediary service where the photo was taken. The text 
g : wallof rant would tell the computer-squirrels to ask the del.icio.us 
API http://del.icio.us/help/api/ for all my posts tags 

del:bookmark=geO http:/ /del. icio.us/straup/del:bookmark=geo , find the 
one titled "wallofrant" (Why the title instead of a tag? Who knows, it was a long 
time ago...) and then pull out the geo : lat and geo : Ion tags and use them to call 
the Flickr geotagging API 



methods http: //www.f lickr.com/ services /api/f lickr. photos. geo. setLocatio: 

This eventually morphed in to sometime completely different called 
(drumroll) delicious 

maps http: //www. aaronland.info/weblog/2 007/0 8/2 4 /aware/#delmaps_02 

but that's also another story and the lesson of trying to use this for photo uploads 
was (another drumroll, please) that I am mostly lazy and could never be bothered to 
add new "photo" places to del.icio.us let alone remember whether the special code 
was "wall of rant" or "wallof rant" . So, what to do instead? 




You're thinking about FireEagle http://www.fireeagie.com/ , aren't 
you? Me too, but back then it was still just a sparkle in Tom's 
eye http://www.piasticbag.org/ so there wasn't any way for my computers to 
talk to his computers and make beautiful mus A H A H A H I mean, powerful synergies. 
Sad face. In the meantime, Dopplr launched a public 

API http://doppir.pbwiki.com/ that allowed you to query for both your 
current location and where you said you'd be travelling on a specific date. 



Angels sing. 



So, I wrote 
Flickr:: Upload: :Dopplr http : / /search . cpan . org/dist/Flickr-Upload- 
Doppir which piggy-backs on top of the excellent 

Flickr:: Upload http://search.cpan.org/dist/Flickr-Upload and 
Net"Dopplr http://search.cpan.org/dist/Net-Dopplr Perl libraries, written 
by Christophe Beauregard and Simon 

Wistow http://defiatermouse.iivejournai.com/ respectively. If you've ever 
used Flickr: :Upload to upload a photo there isn't much difference except for some 
extra Dopplr specific arguments that you need to pass to the constuctor. Like this : 

use Flickr : :Upload: :Dopplr; 

my %dopplr_args = ( ' auth_token ' => ' JONES !!!!', 
'tagify' => 'delicious'); 

my %flickr_args = ('key' => 'OH HA1 ' , 

'secret' => 'OH NOES',, 
'dopplr' => \%dopplr_args ) ; 

my $uploadr = Flickr: :Upload: :Dopplr->new( \%f lickrargs) ; 

my $photo_id = $uploadr->upload( ' photo ' => "/path/to/photo", 
' authtoken ' => ' RLY ' ) ; 

Meanwhile, prior to actually sending the photo to Flickr the library asks the 
photo when it was taken by checking the DateTimeOriginal EXIF header and 
then asking the Dopplr API where you were on that date. (If there is no EXIF data 
then the current date is assumed. So it goes.) What comes back is a big bag of data 
about the city you said you were in including its name (tag!), latitude and longitude 
(geotag!) and a unique identifier in the Geonames http://www.geonames.org/ 
database (machine tag!) Finally, since Dopplr uses different unique identifiers for 
places, the library tries to find a matching sister location in the Flickrverse using the 
flickr .places .find http://www.flickr.com/services/api/flickr.places.find.ht 
API method (profit!). 

Because Dopplr deals in day-long chunks of time it can sometimes happen 
that the space-time tube will eat itself and your photos may end on the other side of 
the country. That's what happened to me shortly after the official launch of 
FireEagle http://deveioper.yahoo.net/biogs/theater/archives/2008/03/fire 
and Dopplr happily told it I had a 09:00 AM flight to 

Austin http://blog.dopplr.com/2 008/03/05/dopplr-at-etech-announcing- 
f ire-eagle-integration/ even though a few short inches of snow in Dallas had 
paralyzed most of the air travel in and out of Texas that day. 



Computers are sometimes dumb that way and I find that I am happier if I 
don't try to fight it. 




The holy grail remains magic-style "talk to the cloud" GPS integration with 
cameras, to record location data, so it was a pleasant shock to wake up one morning 
a couple months ago and see that Nokia had released a freely available piece of 
software called Location 

Tagger http : / /betalabs . nokia . com/blog/ 2 008/01/28 /nokia-location- 
tagger-beta-iaunched/ . Nokia, and others, have been shipping phones with 
built-in GPS units for a while now but until recently they've suffered from battery 
"issues" and generally poor integration with other applications, notably the camera. 
Location Tagger does pretty much what it sounds like : It sits quietly in the 
background until the camera's shutter button is pressed and then it asks the sky for 
its location and writes latitude and longitude data to the photo's EXIF data. 



The answer is yes. It means you can use (drum solo, please) 
Flickr:: Upload: :FireEagle http : / /search . cpan . org/dist/Flickr-Upload- 
FireEagie to not only geotag your photos but, in turn, use your photos to update 
FireEagle itself. 



Angels rock out. 

It goes without saying that the dynamics between where a photo says you 
are, the offset in time engendered by a service that brokers your "location" and what 
you really mean get fuzzy and potentially complicated very quickly. So, this is how 
it works http://search.cpan.org/dist/Flickr-Upload- 
FireEagle/lib/Flickr/Upload/FireEagle.pm#HOW_DOES_IT_WORK? : 

It's a bit involved. 

The first thing that happens is the photo you're trying to upload is 
poked for EXIF data, specifically any GPS information and when it was 
taken (the using *DateTimeOrginal* field) . 

If there is no date information, the current time is assumed. 

If there is GPS data then the date is tested to see if the photo was 
taken falls within an allowable window of time. By default, this is (1) 
hour from "right now". An alternate value may be set by passing an 
*offset_gps* argument, measured in seconds, to the *upload* method. 

If the GPS information was added recently enough then FireEagle is 
queried for your most recent location hierarchy. If the GPS information 
is more recent than the data stored in the hierarchy (the location with 
the "best guess" of being correct) then FireEagle is updated with the 
latitude and longitude recorded in the photo. 

Moving right along, whether or not we've just updated FireEagle the 
service is queried for your current location (again). 

Once the hierarchy has been retrieved, the next step is to try and 
retrieve a "context" node. Whereas when testing GPS information the 
"best guess" node is assumed this is not necessarily the case when 
trying to use FireEagle to add tags. 

The context node is determined by comparing the photo's date against the 
*located-at* (or date recorded) attribute for specific items in the 
FireEagle hierarchy. Since most cameras still don't record GPS 
information it is necessary to do some work to gues"H"H"H I mean infer 
how "close" you are to the last recorded location. 

For example, if it's been more than a couple of hours since you last 
updated FireEagle you might still be in the same neighbourhood but if 
it's been more than half a day chances are good that you're been on the 
move but are still in the same city. 

The following tests are applied : 

* First a "best guess" location is queried 

If it is present and its *located-at* date is less than or equal to 
an hour, it is the context node. 

An alternate value may be set by passing a *off set_f ireeagle_exact* 
argument, measured in seconds, to the *upload* method. 

* Next a location of type "neighborhood" is queried 

If it is present and its *located-at* date is less than or equal to 
two hours, it is the context node. 

An alternate value may be set by passing a 

*of f set_f ireeagle_neighbourhood* (or neighborhood) argument, 

measured in seconds, to the *upload* method. 

* Next a location of type "locality" is queried 

If it is present and its *located-at* date is less than or equal to 
twelve hours, it is the context node. 

An alternate value may be set by passing a 

*of f set_f ireeagle_locality* argument, measured in seconds, to the 

*upload* method. 



* If none of those tests pass then... 
...there is no context node. 

Assuming that a context node has been identified *and* there is GPS 
information stored in the photo, the *f lickr. places . findByLatLon* method 
is called (passing the photo's latitude and longitude) to ensure that 
the (Flickr) places IDs for both the response and the context node 
match . 

If they *don't* match then the context node is destroyed and the 
following tags are added : places :PLACETYPE=PLACEID; woe: id=WOEID; the 
name of the location (formatted according to the object's "tagify" 
rules) . 

On the other hand, if the context node is still around, after all that, 
then it is used to add tags. 

At a minimum a f ireeagle: id=CONTEXTNODEID tag is added. If the place 
type for the context node is equal to or more precise than a 
neighbourhood, the neighbourhood's name is added as a tag. If the place 
type for the context node is equal to or more precise than a locality, 
the locality's name is added as a tag as well as fireeagle:id=ID, 
places :locality=PLACEID and woe:id=WOEID tags. 

We're almost done : Assuming a context node and no GPS information in 
the photo, the nodes latitude and longitude are calculated to use as 
arguments when calling the *f lickr .photos . geo.setLocation* method. 

The coordinates are "calculated" because not every location in the 
FireEagle hierarchy has a centroid. If no centroid is present then the 
node's bounding box is used and the centroid is assumed to be the center 
of the box. The photo's "accuracy" (in Flickr terms) is determined 
according to the node's place type. 

Finally, the photo is uploaded (and geotagged if necessary). 

No really. 



Like Flickr: :Upload::Dopplr, the FireEagle version simply defines a few 
extra arguments to the constructor and then hands all heavy lifting off to Simon 

Wistow's Net: :FireEagle http : / /search . cpan . org/dist/Net-FireEagle 

library. 

<shameless_plug>Please for you to write an extension for the Flickr 

Uploadr http: //code. flickr.com/trac/browser/trunk/uploadr/extensions 

that does the same thing. I am lazy and fear that I will never actually get around to 
doing it no matter how much I say I want to. <i shameless _plug> 

The next step is to work through the two libraries, find the common methods 
and move them into a base class. So far, the only name I've been able to come up 
with is "Flickr::Upload::Locatify" so I would welcome any better suggestions. Once 
that's done I'd like to work out how to structure things so that it is easy for 
developers to chain a series a libraries together to read and write location data 
across services. 



For example, Flickr::Upload::FireDopplr will ... uh, well I'm still working 
through the possibilities. Ask Dopplr for your current city if the FireEagle/GPS 
magic returns nothing? Tell Dopplr to create a new trip if the location data inferred 
from a photo doesn't match your current city? All of the above? 




Something like that, anyway. 
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In both of these naps SF is centred, n the top one. we have Doppl H s default zcoti level of 
4. Because cur gazetteer, Geonanes doesn't have: oou-drp, box data we settled on 4 as a 
reasonable default. Happily. Yahoo's new Geo API has bouncing ocxes induced. 

The lcwe r nap is a result of adding this code to the n - ap: c a s ti e , ca ao o , s e/pas les; 1 9 6 7 4 3 



On Monday, Yahoo! released a public API for its Where On Earth 
database http://deveioper.yahoo.com/geo/ . This is the same dataset that 
Flickr, Upcoming and FireEagle use for doing geo stuff. Rather than repeating 
everything that Dan said, you should just go read what Dan 

Said http: //geobloggers .com/archives/2008/05/12/yahoo-woe-where-on- 

earth-that-is-ids/ but the important parts are : public; unique identifiers; 
methods for resolving the lineage (the parents, children and even neighbours) of a 
"place". 

On let's-pretend-it-really-happened-on-Tuesday, 
Andrew http://en.oreilly.com/where2008/public/schedule/detail/1696 

let it be known that Mapufacture http://mapufacture.com/ will start allowing 
its users to create and print little pocketmod-papernet 

maps http://flickr.com/photos/straup/2494606069/ . 



On Wednesday, Dan was kind enough to ask me to join him on stage at 

Where 2.0 http://fiickr.com/photos/xi8O/2493423994/ to explain what, 



exactly, reverse geocoding is and why it's harder than you'd 

think http://blog.johnmckerrell.com/2008/05/14/where-20-going-places- 

on-f lickr/ . We also announced, what internally we've been referring to as, the 
"Corrections" project whereby you can tell us that no this is not Noe 

Valley http: //where. yahooapis.com/vl /places. q(%2 7noe%2 0valley%2 0san%2 0fr 

but actually the 

Mission http: / /where, yahooapis . com/ vl /places .q( %2 7mission%2 0san%2 0f ranci 

Short-term this will help us to stop making your blood boil every time you geotag a 
photo and longer term we hope to teach the computers to be less dumb about it all 
on the first pass. 

We had a shared 15- 

minutes http://en.oreilly.com/where2 00 8/public/schedule/detail/1687 

to plow through all of this which was a daunting proposition for two people 
naturally prone to tangents and run-on sentences. Somehow we managed to squeeze 
it all in without strip-mining the subject of its flavour, I think. Dan has the full set of 
slides which he'll get around to 

posting http://www.slideshare.net/revdancatt soon, but in the meantime 
this is what I gave him to work with. 

In 2008 1 did not prepare notes for talks which was always a bit risky. I wish 
I had written notes for this one since I still refer back to it. This talk was recorded 
so you can watch Dan and I race-car-chase-bomb our way through the 

details http: //blip, tv/oreilly-where-2 0-conf erence/catt-cope -going- 
places -on- f lickr- the- signif icance-of- geographical -information- in- 

photos-975454 if you're in to that kind of thing. 





-,,,„! 


^■^^ " 


^«n 


Difr TBI 1 


i 


r 

1 in 


I '4 I 


Aware Of Only One Voice ] 


13* 


Aaron Straup Cope 1 

Where 2.0 2008 I 
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On let's-pretend-it-really-happened-on-Thursday, the people from 

Instedd http: //en. oreilly.com/where2 008/public/schedule/detail/4 3 05 

proved that they are pure 

awesome http://instedd.org/technology_field_lab (and that working code 

always wins). 

Finally, on Friday the syndication feeds at Flickr were 

updated http: //api.f lickr.com/services/feeds/geo/? 

id=35034348999@N01&lang=en-us&format=rss_200 to include a woeid element 
for every geotagged photo. This is not anything that you should necessarily feel the 
need to get overly excited about. It's just a tiny piece of plumbing — a nubby- 

bit http: //electronicmuseum.org.uk/2 00 8/04/10/api-the-nubby-bits-on- 

lego/ — that will hopefully let someone build some magic on top of. 

Actually, I think that did happen on Thursday but on Friday there were also 
some tweaks to something I'm not going to talk about before "Corrections" is 
launched except to say that it too is also now better. 

[this is good] 
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Things I Have Written About 
Elsewhere, #1216353600 



Wildcard Machine Tag URLs 



Wildcard Machine Tag URLs 



This post was originally published on the code.flickr.com 
Weblog http://code.flickr.com/blog/2008/07/18/wildcard-machine-tag- 
uris/ in July, 2008. 
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If you're not already familiar with machine tags the easiest way to think of 
them is being like a plain old tag but with a special syntax that allows users to 
define additional structured data about that tag. In turn the magic space hamsters 
that run the site have been trained to recognize, index and allow for searches across 
multiple facets of a given machine tag. 

Machine tags have three parts : a "namespace" which is like a subject or a 
topic; a "predicate" which is a like a property of that topic; a "value" which is . . . 
well, a value. For a more thorough introduction to the subject I'd recommend 
reading the announcement we made in the Flickr API discussion 

group http://www.flickr.com/groups/api/discuss/72157594497877875 

when machine tags were first added to the site. If you'd like to know even more, 
after that, there is good collection of links available on 

del.iciO.US http://del.icio.us/tag/machinetags . 



Which brings us to the part where I tell you that we've added the ability to 



search for machine tagged photos in plain old tag URLs (as well as in tag searches 
on the Flickr search page http://www.fiickr.com/search/ ) using the facetted 
query 

Syntax http: //www. flickr.com/services/api/flickr.photos . search.html 

that has always been available in the API. For example : 

• All the photos tagged " flickr :user=bees" , aka 

Cul http://www.flickr.com/photos/bees/ 

http://www.flickr.eom/photos/tags/flickr:usetebees http://www.fiiekr.eom/photos/tags/fiickr:user.bee 

That's a trick, really. You've always been able to do this since machine tags 
are just tags. The New-New means you can be even more granular in what you are 
looking for. How about : 

• All photos with Flickr users : 

http://WWW.fliCkr.com/phOtOS/tagS/fliCkr.USete http://mw.tlicltr.eom/pliotos/tags/tliokr:user. 

• Or Upcoming.org users : 

http://WWW.fliCkr.COm/phOtOS/tagS/upCOming.USete http: //www. fliekr.eom/photos/tags/upcoming:user. 

• Or even Facebook users : 

http://WWW.fliCkr.COm/phOtOS/tagS/faCebOOk:USete http: //www. tliokr.eom/photos/tags/tacebook:user. 

• Or simply all " users " regardless of service (or namespace) : 

http://WWW.fiiCkr.COm/phOtOS/tagS/* :USer= http: //www. flickr. com/photos/tags/* :user= 

• Maybe ; all the photos in the "flickr" namespace : 

http://WWW.fliCkr.COm/phOtOS/tagS/fliCkr:*= http://www.flickr.com/photos/tags/flickr:*. 

• But, seriously, back to Cal : Cal, across services (or namespaces) : 



http://WWW.fliCkr.COm/phOtOS/lagS/*:USer=beeS http: //www. flickr. com/photos/tags/* :user=bees 

• All Cal. All the time : 

http://www.flickr.com/photos/tags/*:*=bees http://www.tiiokr.oom/photos/tags/>: —bees 

• And no, you can not do this. No ponies for you if you try : 

http://www.flickr.com/photos/tags/":"= 

The wildcard URL syntax is also available for an individual user's tags : 

• These are all my photos that have been machine tagged with either a 

Geonames http://www.geonames.org/ , 
Places http://www.flickr.com/places/ or 

GeoPlanet http://deveioper.yahoo.com/geo/ (nee Where on 

Earth http://geobloggers.com/archives/2008/05/12/yahoo-woe- 
where-on-earth-that-is-ids/ ) locality ID : 

http://WWW.fliCkr.COm/phOtOS/Straup/tagS/*:IOCality= http://flickr.com/photos/straiip/tags/* locality. 

• Or photos in the George Eastman House's 

photOStream http: lit lickr.com/photos/george_eastman_house/ 

that were developed using the daguerrotype process : 

httprfwww.flickr.com/photos/george eastman house/tags/photo:process=daguerreotype http://flickr.com/photos/gec 

Now for the list of caveats and Known-Knowns : 

• At the moment it is still not possible to poke around the hierarchy of a 
given machine tag : all the predicates for a namespace; all the unique 
pairs of namespace and predicates; that sort of thing. It is On The 
List [FIX:trade] and hopefully we can offer up something for you to 
play with, even if it's just in the API to start with, shortly. 



Values in wildcard URLs should are treated the same way regular 
tags are in URLs. That is "sanfrancisco" becomes "sanfrancisco" or 
in machine tag speak : 

*:* -sanfrancisco http://flickr. com/photos/tags/* : *=sanf rancisco 

In the examples above, I've illustrated namespaces that are used to 
denote one service or another. It is important to remember that there 
are no rules http://factoryjoe.com/biog/2008/05/25/machine- 
tagging-relationships/ about what can or should be a 
namespace. Like tagging, the hope is that the various communities 
will arrive at and adapt a consensus according to their needs. 




In the meantime, kick back and enjoy photos taken by people on their 

Dopplr trips http: lit lickr .com/photos/tags/dopplr :trip=/interesting/ , 

photos by people who really really like 

airplanes http: lit lickr. com/photos/tags/aero: *= or photos by people who 
are interested in 

pOSSUmS http: lit lickr .com/photos /tags /taxonomy : f amily=phalangeridae/ 

(not to mention all manner of 

marsupials http: lit lickr .com/photos /tags /taxonomy : subclass=marsupialia/ 



or whatever else comes to mind! 



2008-07-18 
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Dispatches From A Town... 

History Boxes 



pocket M Maps (with apologies to 
Andrew) 



a / e 


,.i .-™ , O Q 


/ 


_--° , 


Q 


Q 


V 




,- S 


O 





1 








"»-.«» 


/ 


s 


/ / x ? '*X. 


a e 





/ 

\ 










I feel kind of bad calling them "pocketMMaps" since the name is only a 
single, easily overlooked, letter away from the pocketmaps that Andrew and 
Mikel built for 

Mapufacture http://biog.mapufacture.com/2008/07/30/pocketmaps-paper- 
maps-of-dynamic-data/ . By the time it gets beyond being a . 1 release I may 
try to find a better moniker but since its written in Python and all the Papernet- 
related software http://aaronland.info/papernet/ has a tradition of stupid 
naming conventions second only to Python itself I figured: Why not? 

pocketMMaps is software for creating PocketMod- 
style http : / /www . pocketmod . com/ books for a map image too large to fit on a 
single page. Maps are generated dynamically and then sliced in to (PocketMod) 
page-sized pieces and re-arranged on multiple sheets of paper so that when printed 
and folded you get a little book with the map laid out in handy 2-page spreads. Just 
like the maps you see in the back of travel guides. It may seem as though I have an 
obsession with destroying the travel book industry but I don't, really. It's just that 
their maps suck and their books are too big to fit in my back pocket. 



It works like this: 



height =11 
width =8.5 
margin = .25 
dpi = 144 

bbox = (45.482882,-73.619899,45.532687,-73.547801) 
zoom = 16 

out = "montreal_pocketmmap .pdf " 

pm = pocketMMap (height, width, margin, dpi) 
pm.load_provider( ' OPEN_STREET_MAP ' ) 
pm . draw ( bbox , zoom) 
pm. save (out) 



When you're done, you end up with a PDF 

file http: //aaronland. inf o/weblog/2008/07/27/invisible/montreal_pocketmma 




pocketMMaps are built on the shoulders of 

ModestMapS http://modestmaps.com/ and WS- 

COmpOSe http://modestmaps.com/examples-python-ws/ , hence the MM-iness 

of the naMMe. Sooner rather than eventually I plan to import the code in to the 
ModestMaps Python 

trunk http: //modestmaps. mapstraction.com/trac/browser/trunk/py but it is 

still very early days feature-wise. The current short list looks something like this: 



Add support for markers, dots, pinwins, etc. and reference indexes just 
like the original 



"pocketnet" http://www.aaronland.info/weblog/2 007/01/24/bacon/#pc 

and ws- 

modestmaps http: //www. aaronland.info/weblog/2 08/02 /05/fox/#ws- 

modestmaps libraries. 

• Wrapper code, or libraries, to generate a map and plot points from a 
source KML, GeoRSS, whatever file just like the orginal mmPDF.php 

library http://www.aaronland.info/weblog/2007/05/21/playa/#mmpdf 
Hello, Dopplr tips http://dopplr.pbwiki.eom/method:tips ... 

• Better font handling and sizing with an eye towards optionally using 
PIL so that 

pycairo http://www.aaronland.info/weblog/2008/07/2 7/invisible#his 
is not a dependency. 

• Try and reconcile some of the more eggregious uses of 
lib_copy_and_paste back in to either the wscompose or 
ModestMaps branches. 

• Tangentially related, writing bloody 

Setup.py http://docs.python.org/dist/setup-script.html files 

for all the stuff in the ModestMaps Python trunk so you don't have to 
run everything out of the same folder. 

• Support for the Metric system because, you know, the whole world uses 
it. 

• Work out the gotchas and best practices for especially large maps that 
span many sheets of paper. Experience shows that a PocketMod book 
with more than five nested sheets of paper kind of sucks. 

• ws-pocketmmap. 

In the meantime, if you are planning to spend the day wandering around a 
new and unfamiliar neighbourhood and just want a simple 

map http: //radar. oreilly.com/2 00 8/08/flickr-burning-man-open-street- 



map . html to print out and take with you, well, now you can. 
Ladies and gentlemen, pocketMMap.py 

0.1 http: //aaronland.info/python/pocketMMap/pocketMMap-O. 1 .tar . gz 

2008-08-27T08:00: 13-0700 
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Thanks to the Crealive Commons Attribution-ShareAlike 2,0 license in use at 
OpenStreetMap, we are able to download and make use of these hand-crafted map tiles to 
improve the street-level resolution of the Beijing map in Flickr. 

After: 




No, really. 
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Dispatches From A Town Called 
Patience 



Depending on how charitable you are feeling "corrections" in Flickr are 
either an admission of failure or an embrace of everything good about community- 
driven data and neo-geography. 

A little bit of history: 




The next two 

Slides http://2007.xtech.org/public/schedule/detail/193 go On to say 

"You won't get more precise than neighbourhood" followed by the even more 
depressing "Turning coordinates into something useful is hard" . I don't remember 
how long it had been since we'd finally stopped displaying neighbourhoods for 
geotagged photos on Flickr when Paul http://www.paranoidfish.org/ gave 
that presentation http://adactio.com/journal/1290/?magnolia-tag=xtech 
but it highlighted why we did. 



The reality is that we have always been surprisingly successful at 
determining a photo's neighbourhood but there have also always been mistakes and 
no one is very tolerant of mistakes about "place". Between plane- living and the 
Internets we may be midway through the process of distilling every place on Earth 



down to one of a half-dozen archetypal city- 
states http://twitter.com/plasticbagUK/statuses/870239659 but until that 

happens trying to affect a person's relationship to the history and geography of 
whatever piece of dirt they call home will continue to be a source of tension. 

Or, if you went to ETech in 2007, being told your photos were taken in the 
San Diego County Jail. In a note to the W3C's mailing list on geolocation 

APIs http: //lists.w3 . or g/Archives /Public /public- 

geoiocation/2008Jun/0059 .html on the subject of reverse-geocoding, I wrote: 



There is always going to be a bias of interpretation in the hierarchy of 
relationships you choose. This is okay, really. 

The simplest example is to contrast the way that Flickr and FireEagle 
handle "localities" since the two sites share an almost exact hierarchy of 
places. Flickr treats anything with neighbourhoods as a locality so in our 
model Duncans Mills, CA (pop. 84) and Mexico City (pop. 19M) are 
assumed to be the same "type" of place. 

FireEagle does not. If you authorize an application to know your 
whereabouts at a "city" level there is an expectation that your actual 
location will be suitably fuzzed (assuming that you share an expectation 
that cities are "big") and in a town of 84 people there's not a lot of room 
to get fuzzy in. 

Never mind so-called disputed places (Kashmir, the West Bank, Cyprus, 
etc.) all neighbourhoods are "disputed" around the edges. (This is often 
true of localities, as well.) 

For example, the rough consensus in San Francisco is that Delores street 
is the dividing line between the Mission and Noe Valley. That said there 
are those people who may live on the one side of the line and very much 
believe themselves to be living on the "other". Our experience has been 
that there are few better ways to pick a fight than to tell someone what 
neighbourhood they are in (and being wrong). 

There is also the problem where the data simply doesn't exist yet or it is 

just old and dusty, sometimes wrong, and often plain weird : 

Manhattan 

Valley http://en.wikipedia.org/wiki/Manhattan_Valley , 

anyone? 



Multiply that by 80 million geotagged photos. 

This is mostly what Dan and I were talking about when we two-man-luged 
our way through a talk about reverse- 

geOCOding http://www.aaronland.info/weblog/2 00 8/05/17/good/#thursday 



at Where 2.0 this spring : Even if we did have a giant database mapping every point 
on the planet (multipled by decimal degrees, multiplied again by "zoom" levels) to a 
place people still wouldn't agree on its contents. 

As useful as the frustration of having photos geotagged in my aparment 
show up in Noe Valley was to understanding and improving some of the issues 
involved in making this stuff work at all there is only so much human subtlety you 
can, literally, codify in to a computer program. 

What if instead of simply trying to keep pace with all of human history and 
predujice as a series of cascading if /else statements we laid our cards — the 
places that we think a pair of latitude and longitude coordinates might be — on the 
table and if we get it wrong give people the chance to tell us what they meant and to 
learn from that? What if the next time you geotagged a photo we compared where 
we think that place is against the places that you've told us are nearby? If not you, 
then your contacts? What if every single person on Flickr points out that a 
neighbourhood, or town, is just plain wrong? 




Dan has written a pair of good blog 



posts http://blog.flickr.net/en/2 008/08/08/introducing-a-new-way-to- 
geotag/ describing the nuts and bolts of how "corrections" works and in the 
nerdier of the two http://code.fiickr.com/biog/2008/O8/O8/iocation- 
keeping-it-real-on-the-streets-yo/ he sums it up nicely by saying: 



On a slightly more philosophical level, it's a never ending process. 
We'll never reach a point where we can say "Right that's in, all borders 
between places have been decided". But what we should end up with are 
boundaries as defined by Flickr users. 



For us, it's a first small step into an experiment, and actually a pretty big 
experiment as we're potentially accepting "corrections" from our 
millions and millions of users. We're not quite sure how it'll all turn out, 
but we're armed with Maths, Algorithms and kitten photos. 



For a lot of reasons (most good, some bad) corrections took a long time to 
make it out the door. Then again, so did geotagging itself and the important part is 
that it's out. We haven't deployed any of the code to test for nearby corrections since 
it's a bit of a chicken and egg problem without, well, corrected data but that should 
follow soon enough. It's a small thing, more like polish and detailing than a full-on 
feature, and like machine 

tags http://code.flickr.com/blog/2 08/0 7/18/wildcard-machine-tag- 

uris/ I don't expect people to get excited about it, right away, but once they need 
it I hope it will shine for them. 

And we've started displaying neighbourhoods again. 

If corrections were difficult to explain to people, describing the changes to 
way we handle airports — and why we should even bother — was often like talking 
to people in whale-song. Very quietly, last May, we updated the reverse-geocoding 
logic to stop looking for the nearest town when a photo is geotagged at an airport 
and instead treat the airport itself as the town. The 



Places http://www.fiickr.com/piaces pages were all updated accordingly and 
now you can type in /places/ 3 -LETTER-AIRPORT-CODE and it will pretty 
much do what you expect (barring those places that need to be corrected, of which 
there are inevitably a few). 

We did this not (only) because I have long read and admired the work of 
J.G.Ballard http://www.jgballard.com/airports.htm but because it is the 
right thing to do. Though, administratively, airports are generally associated with a 
single municipal or regional entity they often serve a range of towns and cities and 
the realities of contemporary travel mean that they have evolved from being simple 

gateways to Captial-P places http : / /books . google . com/books ? 
id=Pp2vlbgmvJEC&dq=airspaces&source=gbs_summary_sSrcad=0 with their own 

culture, norms and gravity. 
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Whatever an airport may be for accounting purposes it rarely matches 
contemporary expectations and experience; no one wants to see pictures of 
Hounslow http://www.hounsiow.gov.uk/ when they go to London Heathrow 
Airport http://fiickr.com/piaces/LHR and vice versa. The latter still 

happens http: //f lickr . com/places /United+Kingdom/England/Houns low 



unfortunately but the hope is that by adding airport and corrections "knobs" (and a 
few others still too soon to talk about) that users can adjust things to their 
understanding of the world and we can begin to map facts on the ground rather than 
from on high. 



2008-08-09T12:21:34-0700 



History Boxes 




Two years ago, we went to 

Europe http://www.flickr.com/photos/straup/sets/72 057594141964933/ 

and when we came back I made a book. Last year, we went to Europe and 

when we came back I made a book with maps. That was the germ which started 
Net:Flickr::GeO http://www.aaronland.info/weblog/2 007/06/08/pynchonite/#i 

f lickr-geo and later my involvement with Modest 

Maps http: //www.aaronland. inf o/weblog/2008/02/05/f ox/#ws-modestmaps . 

We went to Europe 

again http://flickr.com/photos/straup/sets/72157605484879954/ this year 
and I left knowing that when we got back I would make another book, with fancy 
dithered maps, but that's as much as I'd thought about it. During the last two trips I 
had done a lot of work to position and render multiple images which ultimately 
ended with "poster 

maps http://www.flickr.com/photos/mroth/22 42281931/ ", a single large 

scale representation of a group of photos. As pleased as I am with poster 
maps http://fiickr.com/photos/straup/224230842i/ they are only good 
when played loud and not necessarily the best way to share photos from a "trip" . 



Lack of wall space aside I also don't want to look at this stuff every day let 



Photos, licensed under the Creative Commons or the No Known Copyright licenses are by: Aaron Gustafson bennovakovic, 
VirtualErn, SneakyFeet, Lachlan Hardy, Powerhouse Museum Collection, festivefrog, goosmurt and another activist. 



alone be forced to stand up while I'm doing it. Having a book idling around the 
living room means I can pick it up and poke through while I'm on the phone or carry 
them in to the kitchen when I am feeling all weepy-eyed and nostaglic. 

I also now have three years and just over as many books worth of photos 
from 

Europe http://flickr.com/photos/straup/collections/72157 6 00011693939/ 

at this point. Since I am a creature of habit many of the pictures are taken in 
proximity to one another so I thought it would be nice to create a poster map for a 
single photo, instead of a photo set, and show it in the nested among all the other 
photos that I had taken nearby, over 

time http://flickr.com/photos/straup/2599169278/in/photostream/ . 

Cluster maps http: lit lickr.com/photos/straup/tags/clustermap/ 

for lack of any better name. 

I am especially intrigued by the idea of generating cluster maps year over 
year and watching the spaces that I revisit gradually fill in with the echoes of the 
past. A sort of slowed down timeline done in book form where jumping through the 
layers means putting one down one book and picking up another. 

This eventually led to "historical" cluster maps, like the one of the nave at 
St. Andrew's cathedral in downtown 

Sydney http: //www. fiickr.com/photos/powerhouse_museum/2447194401/ 
shown to your right. Historical because it blends the results of two queries for 
nearby photos. The first, (n) days on either side of when the source photo was taken. 
The second, photos taken an equal numbers of days since right now. 

Cluster maps are not really suited to the firehose of photos available on 
Flickr since they mostly just end up being as large or larger than poster maps. As 
they are also constrained to a small area geographically (typically a 1km radius) you 
also run in to the problem where they are "raining" pinwins. What you're seeing in 



the cluster map of St. Andrew's are only photos that properly licensed for this sort of 
thing so you can imagine how many photos you'd get if you decided to not play by 
the rules (don't do that). 

At least not for print, anyway. This sort of thing might sing in the hands of a 
good Flash developer. Either way it was a pleasant exercise in visualizing the 
"history box" that Flickr has become. It always a bit frustrating talking to people — 
especially people who make hardware because that part is still honest-to-god 

hard http://mike.teczno.com/notes/arduino-atkinson.html — and pointing 

out that if they sent us a bounding box (via the 

API http://www.flickr.com/services/api/ ) we'd send them pictures! And 

getting blank stares. 

The thing that's kind of awesome about having 80 million geotagged photos 
(give or take) most of which are public at a time when location aware devices are 
becoming useful enough to bother carrying around is that every ("every") place on 
Earth becomes a kind of Auggie Wren 

portal http://www.npr.org/templates/story/story.php?storyId=4244 9 94 . 



If you think relentless chatter about the 
Papernet http://www.aaronland.info/papernet is bad I've been obsessed with 
Paul Auster's story about the shop owner who photographs one corner in Brooklyn 
every day for 20 years since I read it, well, just about 20 years ago. I love that there 
is record of a shared experience of place with a complete stranger and I love to see 
how the 

Contours http : / /www . openstreetmap . org/user /Mark%2 OWilliamson/diary /2 62 9 

have expanded and contracted. I love that the network explodes the notion of a 
photo album in to an omnipresence and allow me to go for a walk with the past and 
— to simultaneously borrow and abuse 

Neb http : //flickr . com/photos /tags/ neb/ clusters/bencerveny-por trait/ 's 

observation — wrap the present in an onion-skin of subjectivities. 




And mobile devices' increasing tendency to devour our 
attention.,, (Don't get me wrong - I think the iPhone is a 
breakthrough device, but it's a jealous beauty when it 
comes to our attention, to be sure) 



■Q share 



Ipfull 



Well, that's the idea anyway. 

The first pass will probably suck because the current vogue for so-called 
Hertzian 

Spaces http: // varnelis.net/articles/architecture_for_hertzian_space 

doesn't leave much room for anything except devices (or worse, optical-cum-neuro 
implants) nevermind the imagination. I had a conversation with Steve 
Lambert http : / /visitsteve . com/ a while back about wanting to something 
along the lines of the Anti- Advertising 

Agency http://antiadvertisingagency.com/our-mission , to String up fast 

and cheap displays aroung the city to show nearby geotagged photos; real-live 
history boxes. He suggested using white-box ATM machines. 



Rather than devices which live in and are always announcing a perpetual 
present, maybe finding a norm and a practice to give all those dumb terminals that 
surround us the ability to display an awareness of their environment — nearby 
geotagged photos or something like a non-creepy version of Leonard's BlueBall 

hack http://radar.oreilly.com/2008/05/the-results-of-reality- 
mining.html as quasi screensavers on ATM displays — would be more fun, more 



compelling and more meaningful than a crush of people bumping in to each other as 
they awkwardly transpose their personal iPhone space on to the physical world. 




Which is a very long way of saying: The first part was to get radial queries 

working in the FHckr API http://tech.groups.yahoo.com/group/yws- 
f lickr/message/4146 . 

It only took 1 8 months following the release of 

geotagging http://biog.fiickr.net/en/2006/O8/28/great-shot-wnered-you- 
take-that/ so it is extra wonderful to see it become part of applications like 

Frasier Spier's Exposure http://www.connectedflow.com/blog/?p=98 so 
quickly and Matt http://twitter.com/mattb/statuses/862076966 and 
Alex http: //designswarm.com/blog/2008/07/18/uneasy-intimacies/ 's 

subsequent comments are the icing on the cake. The iPhone may not save 
US http://norman.walsh.name/2008/08/04/iPhone but we have to Start 
somewhere (the peanut gallery should refer to my comments about hardware 
vendors above) and this sort of stuff is what makes it all worth it on both the good 
days and the bad days. 



Technically you've always been able to do something like radial queries 
using plain old bounding boxes but this ignores two truths. First, that bounding 



boxes are boring when they're not hard. Second, if you wanted to sort by proximity 
to the center of the box you needed to so manually which meant fetching all the 
results in advance of doing anything with them (like sorting them by distance). 
Pagination is hard when it's not boring. 

There's a lot to be said for just being able to do this: 

ray $flickr = Net : :Flickr : :API->new( . . . ) ; 

my $photos = $f lickr->api_call( { 

'method' => ' flickr. photos. search ' , 
' args ' => { 

'laf => 37.785377, 'Ion' => -122.414852, 

' radius ' => 2 , ' tags ' => ' kittens ' , 

'page' => 1, ' perpage ' => 15, 
}, 

}); 

With that problem out of the way I started the work of updating 
Net"Flickr::GeO http://search.cpan.org/dist/Net-Flickr-Geo/ to fetch 
and layout all the photos. 

The choice to use the square (75 x 75 pixel) thumbnail for nearby photos 
was largely dictated by proximty of all the images to one another and to limit, as 
much as possible, the goal of preventing overlaps from sending everything shooting 
off the map. For that same reason thumbnails that share the same latitude and 
longitude and clumped together in single pinwin whose size is determined by the 
square root (and some fussing) of the total number of images. 




Like poster maps, cluster maps enforce the ws- 

modestmapS http: //modestmaps.com/examples-python-ws /advanced/ bbox 

method which says: Just get me all the tiles you need to display this bounding box at 
this zoom level. At some point, when there are tiles so granular you could read the 
morning's paper on them it should be possible use larger sized thumbnails and still 
stay within the map's "canvas" but not yet. There is still a maximum density (or 
clustering) after which point the map is dwarfed by the space needed to plot all the 
pin wins and there is no room left for anything interesting. 

The bounding box used to fetch the tiles is not the circle-squared of the 
radius but rather the furthest points of the entire result set. This means that the 
principal photo in a cluster map may not always be centered. I suppose it would 
easy enough to make this optional but at least in a book context with many cluster 
maps I like the variety of composition this adds to the collection of images. 



All things being equal, that's pretty much all there was to it. Dream up a new 



layout and ordering for the photos, update the Flickr API (would that it were always 
so easy) and tweak the code that calls it. Profit! 

It's just that when I was generating test maps of photos from the trip to 
SXSW this 

year http://flickr.com/photos/straup/sets/72157604100661498/ I couldn't 

help but notice (again) how ugly and "jaggy" the taller anchors for the pinwins 
were. Having long threatened to update ws-modestmaps to (optionally) use the 
Python bindings for the Cairo vector graphics 

library http://www.cairographics.org/pycairo/ I figured that if I was going 
to spend the money to have a nice book printed I might as well also spend the time 
to create properly aliased pinwins. 

2 2 # DANGER WILL ROBINSON : YOU ARE ABOUT TO 
2 3 # ENCOUNTER CODE THAT WILL MAKE YOU WEEP. 
24 # I KNOW. I CRY EVERY TIME I LOOK AT IT. 

That is from the top of the library that was generating the pinwins when I 
began. The only kind thing I can say about it is that it somehow managed to work 
for as long as it has without completely failing. It's two biggest problems were that 
it was originally developed in tandem with the rest of the ws-modestmaps code and 
carried all the scars of the many, various attempts to get everything working and 
was an absolute clusterfuck of best guesses and approximations for generating 
perspective shadows in the absence of being able to work out the matrix math to do 
it the right way. Math is hard and I chose to go shopping. 

Of course, the first thing I did was try a straight, brute force, port of all the 
old cruft to Cairo. This worked well until I got to the part with the shadows, 
specifically rendering the rounded corners in perspective. The problem I've always 
had with matrix math (used to calculate all the various parameters needed to do stuff 
like a persective transformation) is the absence of any documentation that doesn't 
involve Math Shapes. I can find lots of example "code" but it seems to exist only in 
a theoritical world where demonstrating the concepts using actual numbers as inputs 
and outputs seems to be tantamount to admitting defeat. 

That's the bad news. The worse news was that reproducing the original 
pin win shadow kludge, done using the Python Imaging 
Library http://www.pythonware.com/products/pii/ in pycairo would be even 



uglier and I would have to live with the shame of having knowingly littered the 
world with such shitty and brittle code not once but twice. This isn't a "I was so 
dumb back then" scenario but rather "hear no evil, see no evil" material. 




After about two weeks of chipping away at a whole series of mostly 
incomprehensible matrix-related "tutorials" and one invaluable mailing list message 
written in plain English (which I've managed to misplace in the interim) I was able 
to glean just enough information to start doing tests where I could finally see the 
relationship between all these goofy-ass variables and the actual thing I was 
creating. 

Because there's a lot to be said for just being able to do this: 



m = PinwinMarker(240, 180, 50) 
m. cartoon shadows = False 



ra.drawf ) 

m. save( "pinwin.png" ) 



If you look carefully you may notice that the shadows still seem a little odd 



near the base of the anchor. That's because one of the side effects of blurring the 
shadows is that the shadow itself ends up being obliterated as it approaches the 
point. I decided that it was better to add a little bit of quirkiness (the length of the 
anchor is extended by some factor of itself before it is blurred) at the base of the 
anchor rather than having the shadow taper off midway from the canvas which is 
what happens when you do it the right way. 

(You can also choose to disable blurry shadows at which point everything 
syncs up nices and properly again.) 




Having finally acheived a true and proper Googlesthetic (sic) I ultimately 
opted to leave the "cartoon" version with their funny butler's platter on a giraffe's 
neck shadows as the default. Both versions now use the same perspective 
transformation for the shadow's "canvas" (the bit where the image you want to 
display is placed) but I still think the goofy shadows are warmer, less distracting 
and better suited for cluster maps where the pinwins are often floating in 
whitespace. 



Then, just when I though I was done Dan http : / / geobiogger s . com/ 
pointed out that the shadow from one pinwin should never fall the anchor of 
another. Having implemented his suggestion I'm not sure I still agree but it does 
mean that when you create a pinwin you can ask for any one of three layers: the 
canvas, the shadow or the two combined, ws-modestmaps does this by default first 
adding all the shadows and doing a second pass with the pinwin canvases. 

You can see the effect above, in the cluster map of Sydney, near the shadow 
of the cathedral's nave. If you're like me you may find the zebra-striping and the 
contrast a bit too harsh and be thinking about making it optional in the next code 
release. 

All for a silly photo album. Oh yeah, remember the book? 

Finally, something like a month and a half after getting back from Europe I 
had several hundred test images, a book with cluster maps (and funny bluish 
shadows because of the way blacks and greys are printed these days) and all the 
code to generate them committed to the CPAN and the ModestMaps SVN tree. That 



Net::Flickr::Geo.pm 0.72 http://search.cpan.org/dist/Net- 

Fiickr-Geo-o .72/ — this contains new methods to generate cluster 

maps http: //search. cpan.org/dist/Net-Flickr- 
Geo/lib/Net/Flickr/Geo/ModestMaps .pm#CLUSTER_MAPS for a single 
photo, an entire photoset or an "historical" cluster map for a photo. 

ModestMaps, rev. 

637 http: //modestmaps .mapstraction.com/svn/trunk/py/wscompose/ 

— this contains no user-facing changes, beside the way the shadows 
are drawn. Under the hood ws-modestmaps will silently check to see if 

pycairo http://www.cairographics.org/pycairo/ is available and 

use it if it is. The new pinwin code comes with a bunch of knobs and 
toggles which I would like to expose in ws-modestmaps but that is 
going to wait until I get around to making the core service 

WSGI http://www.wsgi.org/wsgi/ compliant. 



Two other packages have been released separately, though they are both 
installed automatically as a dependency or included by default with the software 
listed above. They are: 

• Net::ModestMaps.pm 1.1 http://search.cpan.org/dist/Net- 
ModestMaps-1 . l . tar . gz — a simple wrapper object for calling a ws- 
modestmaps server in Perl (and preventing 

LWP::Vser Agent http : / /search . cpan . org/dist / libwww- 
peri/iib/LWP/userAgent . pm from freaking out when it's passed 
several hundred HTTP response headers). 

• pwmarker.py 

1.0 http: //aaronland.info/python/pwmarker/pymarker- 

l.o. tar . gz —all the pinwin code discussed above but packaged 
independently of Modest Maps. This will work with both the Python 
Imaging Library or the Python Cairo bindings but in either case 
requires the former. 




Having recently had to rebuild my laptop from scratch I can attest to the part 
where none of this is a simple one-click install yet. My only defence is that there are 



only so many hours in the day and these are the stars I am looking at, right now. If 
it's any help, at least on a Mac it's a reasonably straightforward albeit lengthy 
process using MacPorts http://www.macports.org/ and the 
CPAN http://search.cpan.org/ (assuming of course you've also installed the 
OS X developer tools). These are some of my notes: 

# py25-cairo (macports; this will install Python) 

# py25-pil (macports) 

# libgd2 (macports; this will install perl for some crazy reason) 

# p5-GD (macports) 

# p5-XML-LibXML (macports) 

# p5-XML-XPath (macports; installs p5-XML-parser) 

# symlink all your perl and Python related binaries from /opt/local/bin 
to /usr/bin and /usr/local/bin 

# Bundle: :CPAH (cpan) 

# force install Geo: :Distance (cpan; there's a bad test that I need to work 
around in N:F:G) 

# Net : :Flickr : :Geo (cpan; installs the remaining perl modules) 

Software is for humans, right? 

Meanwhile, while all that was going on Andrew announced that 
Mapufacture has launched their PocketMaps 

feature http: //blog.mapuf acture.com/2 008/ 7/30 /pocketmaps -paper-maps - 

of -dynamic-data/ , which will generate mmPDF- 

Style http:/ /www. aaronland.info/weblog/2007/05/21/playa/#mmpdf 

PocketMod booklets for the maps you create on their site. If I ever manage to finish 

writing this blog post the next bits to bubble to the top of list should start to see a lot 

of the work described above rolled back in to some of the earlier Papernet begets 

PocketMod begets *-PDF related projects where all this nonsense started in the first 

place. 




See also: The Tate's Your 
Collection http : / /www . tate . org . uk/britain/yourcollection/ pamphlets. 
Because they are fucking 

awesome http : / /www . tate . org . uk/britain/yourcollection/pdf /bigmeeting . pc 

that's why! 



2008-07-27T 18:09:51 -0700 




Tree planting and tree 
hugging in the age of 
personal informatics 



The pattern of things within the confusion of. 



"The pattern of things within 
the confusion of details" 




I spoke at Design 

Engaged http://www.designengaged.com/ , last week. I gave a 
bit of a hand-wavey talk called "Capacity Planning for Meaning (in 
the age of personal informatics)". Hand-wavey because it was 
basically a series of hunches hung together with some funny slides 
but also because it seems to be what I do when I speak. There are 
too many pictures of me caught with my hands out, fingers 
extended, trying to direct invisible meme-lasers at the audience to 
deny the obvious. At the end of it all, I felt a little like I did after the 
first Papernet talk in 

2007 http://www.aaronland.info/papernet/ : Pleased that I 
had bothered to try to make the argument, wishing I had a chance to 
do it again to work out the kinks and very much unsure whether I'd 
made any sense or anyone even cared. 



These are not my presenter notes. As I mention below in 
2008 1 had yet to start writing out talks in long-form. Once in a 
while I would try to recap the arguments in a blog post. This is one 
of those times. This is what I wrote, at the time, casually mixed in 
with my slides which used to be included as an <embed> to 
Slideshare. If the words and pictures seem a little out of sync that's 
why. 




I take some solace in the fact that the 
Papernet http://delicious.com/tag/papernet is Still 
chugging along and I can argue its case in a more or less coherent 
fashion now whether its in elevator or rambling, drunken tirade 
mode. I don't usually write notes for my talks instead using each 
slide as the cue for an argument over drinks so the early days 
sometimes sound like crazy-talk. But since everyone told me that 
Design Engaged was an opportunity for more crazy-talk than not I 
figured I would try to jump in with both feet. 



"We should be mapping information that in 

some ways has been historically 

unmappable because it is 1) not valued or 

is 2) actively seen as threatening or is 3) 

simply too hard to map using traditional 

tools." 



selm Ho 



I also had a meat- 
hangover, http : / /www . f lickr . com/photos / straup/ 2 911339177/ 



"It is this narrow definition of context that 
makes life harder for ourselves, because 
adding more and more sensor readings is 
not really the same thing as adding more 
and more context." 



_wn Naf 



The talk starts by taking both the enthusiasts and the 
pessimists at their word that the world has a serious sensor-porn 

habit http: //www. studies -observations .com/everyware/ 
(that's fancy-talk for "ubiquitous computing") it's not going to give 
up any time soon. It also assumes that it might not be all bad. 
Specifically, that whatever other challenges a change like this 
presents there's something in it all worth making sure we don't fuck 
it up. 



'Your focus on implementation details is 
limiting your imagination." 



Man Elliott-McCr 



As a rule, talk about ubiquitous computing breaking has 
centered around social abuse: What happens when a badly designed 
system negatively impacts you. This is usually equal parts a call to 
ensure that users can always save face and that services aren't 
creepy. All good. So I didn't bother talking about those. Instead I 
asked people to imagine two other possible breaking points. 




The first simply being that everything breaks and that those 
things which fail often enough and with no grace are usually fast 
ignored and forgotten. If the lowly smoke detector was one of the 
earliest pieces of ubiquitous computing what does it mean that most 
of us, at some in our lives, simply rip the battery out of its casing 
and then can't bring ourselves to reactivate it despite all the evidence 
to the contrary? If the "pocket call" is the smoke detector of personal 
informatics what does it mean that you are powerless to even rip the 
battery out, so to speak, when your phone gets stuck at the bottom of 
their bag and sends 144 blank text messages in 28 minutes? It would 
be like the smoke detector storing up fifteen minutes of smokey 
siren music to replay six hours after the oatmeal stopped burning. 




As it turns out, you're kind of fucked if it ever happens. 




This is not Clay Shirky's filter 

failure http://web2expo.blip.tv/file/1277460/ : It is not 

people failing to adapt to the future. It is not even bad design. 
Everything breaks, so what happens when we wire the world on the 
sort of massive scale being proposed and every day is more irritating 
than the next? Probably what will happen is that people will just 
walk away from the entire project damning it first with market 
insignificance and if that doesn't work then rendering it meaningless 
with government regulation. So it's something at least worth talking 
about. 



it is morning IN DAN CATT'S PANTS again 



08:08 AM June 19, 2008 from web 






08:08 AM 






The second question was how this stuff breaks us and was 
inspired by Rusty Schweickart's talk about near earth objects 
(you know, asteroids) at a NASA/Brickhouse 

lecture http://upcoming.yahoo.com/event/869496 last 
summer. The really short version is that we don't see most of the 
billions und billions of asteroids hurtling towards us today and that 
our situation is akin to standing in a field with your eyes closed 
while a pitching machine launches baseballs at you. The chances 
that you'll actually get hit by one are basically nil until you open 
your eyes, get tweaked by the situation and start ducking. 
Essentially by reacting you magnify the chances of being struck by a 
baseball. 



98 INVISIBLE MESSAGES in 4 blocks - 
please for DAN CATT'S PANTS to be 
travelling faster than I am... 



08:31 AM June 19, 2008 from txl 



08:31 AM 



That got me wondering: What are the equivalent "near earth 
objects" for all this data we're collecting and turning into our own 
personal 24-hour news channels? If we are hard- wired to rubberneck 
traffic accidents, beautiful people and data (especially when it's 
about ourselves) where are the stress points that will cause us to 
binge and purge? 



Gasping for breath in a Jonesfieldian cloud 
of INVISIBLE AMBIANCE 



08:36 AM June 19, 2008 from Ixt 
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08:36 AM 






"Adaptability" is usually the counter-argument: Those who 
come after us will adapt and take it for granted. Like the sewer 
system, for example, no one will get excited about, or even reflect 
on, the Internet and ubiquitous computing in time. I think that's a bit 
of a red herring really. The point is not that we won't adapt to the 
volume (I don't actually think we do but instead just become more 
and more forgiving of each other's distraction but that's another 
story) but that in the volume we're proposing to bring on line there is 
probably something we've never seen before that will do more harm 
than not despite ourselves. 



We should be asking ourselves what those things are, or 



might be. 




So, no answers. Only conceptual, hand-wavey questions 
about a not impossible future. 



The other semi-constant in all of these discussions is that it is 
the teenagers (and occasionally financial analysts) unburdened by 
the baggage of the past (or maybe just hopped up on sugar) who will 
guide us through this new and strange territory. Aside from the long 
list of concerns I have with either possibility, it seems to me that 
there is a also another group of people who drink from the firehose 
of the constant now and from whose professional disposition we 
could maybe learn something. 



KELLAN'S PANTS are my new DAN CATT'S 
PANTS 

08:56 AM June 24, 2008 from web 



Kill me now 






John Allspaw http://highscalability.com/how- 
succeed-capacity-planning-without-really- trying- interview- 
flickrs-john-aiispaw-his-new-book has written that: "Capacity 
planning is a term that to me means paying attention. Web 
applications can fail in all sorts of dramatic ways, and you're not 
going to foresee all of them. What you can do, however, is make use 
of what you do know about what happens in your real world on a 
regular basis. ... You're not going to predict every failure mode of 
the whole system, but knowing the failure modes of individual pieces 
should be considered mandatory. Armed with that, you can make 
decent forecasts about the future." 











Ubiquitous 









And Leonard Lin http://randomfoo.net/blog/id/4171 
has written that "In a perfect world, you 'd have perfect capacity 
planning and infinite resources, but if you've ever experienced real- 
world hockey-stick growth on a startup shoestring, you know that's 
not the case. If you have, you understand that scaling is the brick 
that hits you when you've gone far beyond your capacity limits and 
when your machines hit double or triple digit loads. Architecture 
doesn't help you one bit there. And the people that have experienced 
this and lived to tell the tale also know that it's impossible to critique 
the technical/operational aspects made w/o seeing and 
understanding the QPS targets, load graphs, profiling datalsar info 
and all manner of other architectural! technical data and details 
(that none of us are privy to) before commenting with any sort of 



authority." 





H Battlestar Galactica Hybrid impersonation 

■ I 




The future was 20 minutes ago 1 


lb ,„,„„.] 


_j 





Operations people. You know, the people who keep your 
websites running and the people who are increasingly being asked to 
keep your websites running under increasingly noisy circumstances. 




Operations people spend a huge amount of their day ensuring 
that they are not woken up at two in the morning and asked to put 
out fires. To that end the rule of thumb is record and graph 
everything and understand what the high and low water marks are to 
help recognize a situation that needs attention versus one that 
doesn't. 




They deal with a volume of information and changing 
circumstances that mirrors, or at least foreshadows, the magic 
happy ambient-aware spime- 

WOrld http : / /www . vir idiandes ign . org/ 2 006/03 /vir idian- 
note-00459-emerging.html we assume is already underway and 
have developed tools and coping mechanisms to monitor, visualize 
and ultimately try to make sense of things. It seems to me they 
probably have something useful to add to the conversation. 



True story: YHOO's share price, one morning. 



Aggregated it ysql .updates for DB-Flaux 
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At the same time, they could use some help. One of the great 
skills of operations people is the ability to pick up almost any piece 
of software, no matter how poorly written or documented, and learn 
how to use it. That's not necessarily a burden we should ask of 
everyone else, though. There is not usually the luxury of capital-D 
design outside the purely functional with most of these tools and 
their usefulness, or at least their lessons learned, will be lost on most 
people without it. 



Aggregated bulletmailr_email_&ent for WWW 




Week 19 
I wwwl .flickr. mud. yahoo . com 
I www 3 .flickr.mud. yahoo . com 
I www5 .flickr.mud. yahoo . com 
I www/7, flickr .mud .yahoo .com 
I www9 .flickr.mud. yahoo . com 
I www 11 . flickr . mud. yahoo.com 



Week 21 Week 22 

■ www 2 .flickr. mud, yahoo, com 

■ www4 . flickr. mud. yahoo. com 

■ www6 .flickr. mud. yahoo. com 

■ www8. flickr. mud , yahoo .com 
I wwwlO . flickr. mud. yahoD. com 
I www!2. flickr . mud .yahoo .com 



Operations people. Really. 
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Translation: STFU 



At this point without saying so explicitly I crashed my talk 
head-first in to the design vs. art, art vs. craft, craft vs. design 
debate. 



Which was sort of crazy since I'd already run off at the 
mouth long enough to get the two-minute warning and I wasn't sure 
what I was trying to get at except to say "we've been here before" 
(which I had said twice, already). 
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But what does it mean? 



Stamen http : / /www . stamen . com/ has pretty successfully 
laid claim to, and proven, the idea that data visualization is a 

medium http : / /www . we-make-money-not- 
art.com/archives/2008/03/etech08-information- 
visualizat . php . They've often talked about presenting the data in 
its entirety (more or less) and letting people prune it themselves and 
Mike Migurski (from Stamen) did a great presentation about the 
future-past of 

tiles http://mike.teczno.com/notes/de2008.html and talked 
about some of the opportunities that "really-realtime event-based 
notifications" present. 




When I wrote all of this John Allspaw would not do a talk 
titled Considerations for Alert 

Designs http: //www. slideshare.net/jallspaw/alert- 
designcac-taik20i3 for another five years. If he had I almost 
certainly would have mentioned it here. 




In contrast, I pointed out works by the painters Wayne 
Thiebaud and Richard 

Diebenkorn http://flickr.com/photos/pstar/397375505/ 
who each became landscape painters, in San Francisco and Santa 
Monica respectively, in their later careers. Both painted very 
different but highly stylized representations of the cities they lived 
in that are easy to appreciate for purely aesthetic reasons. At least 
that was my experience but living in California for three years has 
brought a whole new richness to their work that was hard to 
appreciate until I learned the funny way you tilt-shift your way 
through the day-to- 
day http://www.royalbaronialtheatre.com/blog/2008/09/flip- 



camera-tilt-shift-visual-experiments . html in either place. 




I mention this because it's fun to see their works not as the 
representation of a single moment but as the all the extra sensory 
overload that comes with city life which we normally filter out and 
ignore "massaged by hand to eliminate air 

pockets http://en.wikipedia.org/wiki/Botarga , then dried 
and cured ... sliced thinly or grated." Which is a lovely way to think 
about dealing with all this invisible ambience that surrounds 

US http://vimeo.com/1166968 . 



I totally stole that link from 
Timo's http://www.eiasticspace.com/ presentation, later that 
morning, by the way. 







f*n 




Ceci n'est pas un bar chart 
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The contrast wasn't to criticize the work that Stamen and 
others are doing but rather to use them as a foil and stick my finger 
in the pie to ask the vague and rhetorical question: What can the 
lessons of absraction teach us about managing all this data we're 
going to collect about 

Ourselves http: //www.azarask. in/blog/post/track-anything- 
for-40/ ? Gardening, so to speak. 




Inside the high and low water marks of meaning the last 
thing I need is another real-time dashboard or "Where's Godzilla?" 

window http://flickr.com/photos/dunstan/2792316953/ . 
This is the place where there is still the freedom to play and the time 
to nose around and find what Ben 

Shahn http : / /www . f lickr . com/photos / straup/2 9 01753697/ 
called the "pattern of things within the confusion of details" . 




It's something to aspire 

to http://www. flickr.com/photos/brevity/sets/164195/ 
while we're busy being crushed by the implementation details. 



2008-09-29T19:30:23-0700 




Things I Have Written About 
Elsewhere, #1225339200 



The Shape of Alpha 



The Shape of Alpha 



This post was originally published on the code.flickr.com 
Weblog http://code.flickr.com/blog/2008/10/30/the-shape-of-alpha/ in 

October, 2008. 

We have a lot of geotagged photos 

Almost ninety million, as I write this, and the numbers keep growing 
especially as nearly every new "smart" phone released to market has not only a 
camera but also the ability to capture location information with it. 

For every geotagged photo we store up to six Where On Earth 
(WOE) http://deveioper.yahoo.com/geo/ IDs. These are unique numeric 
identifiers that correspond to the hierarchy of places where a photo was taken: the 
neighbourhood, the town, the county, and so on up to the continent. This process is 
usually referred to as reverse- 
geocoding http://code.fiickr.com/biog/2008/09/04/whos-on-first/ . 

Over time this got us wondering: If we plotted all the geotagged photos 
associated with a particular WOE ID, would we have enough data to generate a 
mostly accurate contour of that place? Not a perfect representation, perhaps, but 
something more fine-grained than a bounding box. It turns out we can. 

So, starting today there are 150,000 (and counting) WOE IDs with proper (- 
ish) shape data, available via the Flickr 
API http://www.flickr.com/services/api . What kind of shapes, you ask? 

Continents: 
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Countries: 





States and cities: 





Even neighbourhoods: 
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Each one of those illustrations represents the boundaries of a particular place 
whose outline was generated using nothing but the latitudes and longitudes of the 
geotagged photos associated with that location's WOE ID. No 

GIS http: //en. wikipedia.org/wiki/Geographic_information_sy stem 
information was harmed in the creation of these shapes. 

How cool is that?! 



How does it work? 



The short version is: Scary and complicated maths. The longer version is: 
We are generating alpha 

Shapes http: //biogeometry .duke. edu / software /alphashapes/ index. html 

using the set of unique latitudes and longitudes associated with a WOE ID. The long 
version, to quote Tran Kai Frank Da and Mariette 

YvineC http: //www. cgal.org/Manual/ 3 . 2/doc_html/cgal_manual/Alpha_shapes 

is: 



"Imagine a huge mass of ice-cream making up the space . . . and 
containing the points as "hard" chocolate pieces. Using one of those 
sphere-formed ice-cream spoons we carve out all parts of the ice-cream 
block we can reach without bumping into chocolate pieces, thereby even 
carving out holes in the inside (eg. parts not reachable by simply moving 
the spoon from the outside). We will eventually end up with a (not 
necessarily convex) object bounded by caps, arcs and points. If we now 
straighten all "round" faces to triangles and line segments, we have an 
intuitive description of what is called the alpha shape. . ." 



(There are also some useful illustrations of what that all means on Francois 
Belair's Everything You Always Wanted to Know About Alpha Shapes But 
Were Afraid to 

Ask http: //cgm.cs.mcgill.ca/-godfried/teaching/projects9 7/belair/alpha.] 

website.) 

The community of authority and the authority of 
community 

This is the important part: Many, if not most, of these shapes will look a 
little weird. Possibly even "wrong". This is both okay and to be expected for a few 
reasons, at least. 

• Sometimes we just don't have enough geotagged photos in a spot to 
make it is possible to create a shapefile. Even if we do have enough 
points to create a shape there aren 't enough to create a shape that 



you 'd recognize as the place where you live. We chose to publish those 
shapes anyway because it shows both what we know and don 't about a 
place and to encourage users to help us fix mistakes. If the shape of the 
neighbourhood is incomplete or looks weird why not consider 
organizing a 

photOWalk http: //www. flickr.com/photos/tags/photowalk/map 

around its edges and when you get home add them to the map. The next 
time we generate a new shapefile for that neighbourhood it should look 
more like the place you recognize! 

We did a bad job reverse geocoding photos for a particular spot and 
they've ended up associated with the wrong place . We've learned quite 
a lot about how to do a better job of it in the last two years but there is 
a limit to how much human awareness and subtlety we can codify. 
Sometimes, the data we have to try and work out what's going on is just 
bad or out of date. Ultimately, that's why we added the tools to help 
users correct their geotagged 

photos http://code.flickr.com/blog/2008/08/08/location- 
keeping-it-real-on-the-streets-yo/ SO that we Can adjust things 

to their understanding of the world and begin to map facts on the 
ground rather than from on high. 

We are not very sophisticated yet in how we assign the size of the alpha 
variable when we generate shapes. As far as we can tell no one else 
has done this sort of thing so like reverse-geocoding we are learning as 
we go. For example, with the exception of continents and countries we 
boil all other places down to a single contiguous shape. We do this by 
slowly cranking up the size of the ice cream scoop which in turn can 
lead to a loss of fidelity. Does the "shape " of Florida, or of Italy, 
include the waters that lie between the mainland and the surrounding 
islands? It's not usually the way we imagine the territory that a place 
occupies but I think it probably does. On the other hand, including the 
ocean between California and Hawaii as "part of the United States 
would be kind of dumb. 

Are any of these the correct decisions? We're not sure yet. 



A concrete example to illustrate the point. Here are two versions of the 
island of Montreal http://www.flickr.com/places/Canada/Quebec/Montreal 
each generated from the same set of coordinates. The version on the left used an 
alpha number (an ice cream spoon) large enough to ensure that only a single shape 
was created compared with the version on the right that allowed for two shapes. 




What's going on, then? All those photos taken in St. Jean-sur-Richelieu (20 
minutes south of Montreal) were added to the map back when we first added 
geotagging to the site and the information about the province of Quebec was not as 
detailed as what we have now. Ultimately, we decided to include the version on the 
left because as Matt Jones recently 

Said http: //magicalnihilism.wordpress .com/2008/10/ll/bionic-noticing- 
on-irving-street/ : 



"The long here that Flickr represents back to me is becoming only more 

fascinating and precious as geolocation starts to help me understand how 

I identify and relate to place. The fact that Flickr's mapping is now 

starting to relate location to me the best it can in human place 

terms http://code.flickr.com/blog/20 08/09/04/whos-on- 

f irst/ is fascinating - they do a great job, but where it falls down it 

falls down gracefully, inviting corrections and perhaps starting 

conversation http://www.flickr.eom/photos/blackbeltjones/2 92 0892513/#coimi 



As with any visualization of aggregate data there are likely to be areas of 
contention. One of the reasons we're excited to make this stuff available is that 



much of it simply isn't available anywhere else and the users and the developer 
community who make up Flickr have a gift for building magic on top of the API so 
we're doubly-excited to see what people do with it. 

That said please remember that this it is an aggregate view of things and 
should be treated more like the the Zeitgeist of a 

place http://www.flickr.eom/places/US/CA/SF#zeitgeist and not as capital- 
C confirmed facts on the ground or our taking sides in any conflicts (real, imagined 
or otherwise) between friends and neighbours. 

These are not maps you should use to guide your spaceship back to Earth but 
they're probably good enough to explore the possibilities. 

Clustr 
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Meanwhile, back in the nuts-and-bolts department: The actual alpha shapes 
are generated by a program called Clustr, written for us by the fantabulous 
Schuyler Erie http://iconocla.st/cv.html . 



Clustr is a command-line application written in C++ that takes as its 



arguments the path to a file containing a list of points (the hard chocolate pieces) 
and an alpha parameter (the ice cream spoon) and generates a 
Shapefile http://en.wikipedia.org/wiki/Shapefile describing the contour 
(the alpha shape) of that list. Anecdotally, we've seen Clustr plow through a file 
with four million unique coordinates (representing the continental United States, 
Alaska and Hawaii) in under three minutes on some pretty modest hardware. 

The shapedata for a WOE ID is available via the Flickr API using the 
flickr .places .get Info http://www.flickr.com/services/api/flickr.places.getl 
method. 

Not all places have shape data yet so the root <place> element contains a 
has_shapedata attribute for checking at a glance. Otherwise you can test for the 
presence of a <shapedata> element. It will look like this: 



<place place_id="4hLQygSaBJ92" woeid="3534" 

latitude="45.512" longitude="-73 . 554 " 

place_url=" /Canada /Quebec /Mont real" place_type=" locality" 

name="Montreal, Quebec, Canada" 

has_shapedata= " 1 "> 

<! — all the usual places hierarchy elements — > 

<shapedata created="1223513357 " alpha="0. 012359619140625" 

count_point s= "34778" count_edges=" 52 " > 

<polylines> 

<polyline> 

45.427627563477,-73.589645385742 45.428966522217,-73.587898254395, etc. . 

</polyline> 

</polylines> 

</shapedata> 

</place> 



Sometime next week, we will also include links to a real live ESRI 

Shapefile http : //en.wikipedia.org/wiki/Shap e fil e , the well - known and 

mostly - loved lingua franca of the GIS community, for each WOE ID. They were 
supposed to be included with this release but because of a last minute glitch they 
need to be prettied up a little first. We think that the inclusion of the polylines will 
be enough to keep people busy until then. Shapcfilcs will be included, in the API, as 
a link to a compressed file you can download separately. For example: 

Update: The first round of (ESRI) 
shapefiles http://en.wikipedia.org/wiki/shapefiie have been reprocessed 
and are now available via the API. Shapefiles are included as a link to a 



compressed file you can download separately. For example: 



<urls> 
<shapef ile> 

http://farm4.static.flickr.eom/9999/shapefiles/3534_20081020_S3 3KR3TSHAPE.t 
</shapef ile> 

</urls> 



Our plan is to generate new renderings on a relatively constant basis, 
something like every month or two, though we haven't firmed up any of those 
details yet. We'll post about them here or on the API mailing 
list http://tech.groups.yahoo.com/group/yws-flickr/ as things are worked 

out. 

But wait, there's more! 

Along with the shape data the source code for Clustr is available in the 
Flickr Code repository http://code.flickr.com/svn/trunk/clustr/ and 

through our trac 

install http : / /code . flickr . com/trac/browser/trunk/clustr , distributed 

under the GPL (version 2) http://www.gnu.0rg/iicenses/gpi-2.o.htmi . 

Clustr has two major dependencies not included with the source that you will 
need to install yourself in order to use. They are the Computational Geometry 
Algorithms Library http://www.cgai.org/ (CGAL) and the Geospatial Data 
Abstraction Library http://www.gdai.org/ (GDAL). Both are relatively 
straightforward to install on Linux http://packages.ubuntu.com/ and 
BSD http: //www. freshports .org/ flavoured operating systems; Windows and 
OS X are still a bit of a chore. 

You probably won't be able to download Clustr and simply plug it in to your 
awesome web-application today but I am hopeful that in time the community will 
develop higher level language (Perl, Python, Ruby, you name it. . .) bindings to 
make it easier and faster to write tools that build on the work we've done so far. 




By the way, there is a still a known - known bug in Clustr rendering "interior 
rings" (the donut holes where there arc no gcotaggcd photos) in shapcfilcs. 
Specifically, they holes arc rendered as actual polyline records. You can sec an 
example of the problem in the scrccnshot of the shapcfilc for North America, above. 
We hope to have a proper patch in place by the time we make the ESRI files 
available next week. As it is since the problem only manifests itself for countries 
and continents it seemed like a reasonable thing for a version 0.1 release. 

Update: Clustr 0.2, with a fix for errant interior 
rings http: //code. flickr.com/trac/changeset/461 , has been checked in to 
the code.flickr.com SVN 
repository http://code.flickr.com/svn/trunk/clustr/ . 

Finally, these are early days and this is very much a developer's release so 
we look forward to your feedback and also hope you will be understanding as we 
learn our way around the gotchas and quirks that will no doubt pop up. 



In other geostuffs 

In other geostuffs, we have enabled Open Street Maps tiles for two more 
cities: Baghdad and Kabul and George has written a fantastic post highlighting 



some of the photos we've found in both 

Cities http://flickrtheblog.wordpress.com/2 008/10/30/more-cities/ SO go 
and have a look. 




Enjoy! 
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The hills are alive with the sound of 
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I rode the train from New York to Boston, last October. 

Because I haven't yet implemented a local tile cache in 
ModestMaps http://www.modestmaps.com/ (well, I have actually but that's 
another story) I decided to work on the index pages for the 

pOCketMMap http://www.aaronland.info/weblog/2008/07/2 7/invisible/#poc]< 
of Montreal I'd offered to make for Design 

Engaged http : / /www . aaronland . inf o/weblog/ 2 008/10/08 /tree#pattern . 
What started out as a casual suggestion to generate some simple, possibly annotated, 
paper maps that people could walk around with during the weekend quickly turned 
in to a gargantuan MyMaps database http : / /maps . google . com/maps /ms ? 

ie=UTF8&hl=en&msa=0&msid=106 6700487592008 8 1360. 0004565744030ff07d00e&z=i: 

spanning neighbourhoods that would never be visited and completely unrelated 
random events from my past. 



But why the hell not. I've needed to put the giant list of things to do in 
Montreal in one place for a while now and there's nothing like having too much of 
something to demonstrate how the thing that will hold it is going to break. 
Specifically: 



• If you have too many points spread over too wide an area (the 
bounding box used the determine the actual map image for a 
pocketMMap) then you '11 end up with an image that spans to many 
sheets of paper to fold and nest. Experience has shown that three sheets 
is the upper limit which really means that four is possible and two is 
borderline manageable. A single sheet of paper remains the ideal and 
I'll touch on that more below. 

• If you decide to limit yourself to a fixed number of sheets then the only 
way you can fit the entirety of an otherwise oversized viewing area is to 
zoom out. This has two consequences. First you reduce the fidelity of 
your underlying map. This is a visualization problem in and of itself 
exacerbated by the mundane realities of consumer grade printers. 
Secondly, if you have a lot of items to render then you also collapse the 
physical paper-space on which they can be rendered meaning you have 
to play tricks to make all the markers fit in a limited space. This usually 
involves floating markers on some kind of visual anchor unless of 
course that means the anchor bleeds off the page in which case you 
have to get your hands dirty with collision detection algorithms and 
hope that you don't then end up covering the entire map surface with 
markers. (That would be depressing, boring and ultimately defeat the 
purpose.) 

Since I'd already decided to aim for fail I settled on four sheets. So, Monday 
morning came and I was on a train sitting at a table with three lawyers from what I 
guessed was a big New York City real estate firm deep in talk of the end days and 
other water cooler banter with no network connection. 

pocketMMaps are created as PDF files using the 
ReportLab http: //www. reportiab.org/ Python libraries, a handy set of helper 
tools for generating the actual PostScript code that make up a PDF file. PostScript 
was created by Adobe and remains the Wintermute of programming languages. 
The great unresolved question is whether Damian Conway's talk about 

programming in Klingon http://prometheus.frii.com/~gnat/tmp/damian- 
lif e .mp3 served as the design document for the language or whether the 
presentation is merely a reflection of what passes for rational thought at Adobe. 



Which is to say: No one ever writes plain old PostScript when they can avoid it. 




Which is to say: We're all share-cropping on the helper libraries we can't be 
bothered to write ourselves. 



Which is to say: ReportLab doesn't have an option to rotate text; a problem 
when creating an index of table of contents for a PocketMod-ish document what 
with the individual "pages" laid out 180 degrees from one another. The FPDF 
library http : / /www . f pdf . org/ , written in PHP, does and long-time readers will 
remember that all of the original PocketMod and Papernet related 

work http: //www. aaronland.info/weblog/2007/01/24/bacon/#pocketnet 
was built on top of it. But ModestMaps is written in Python and I didn't feel like 
porting all that code to PHP which led, instead, to me writing a bare-bones 
webservices interface to 

ModestMaps http: //www. aaronland.inf o/weblog/2008/02/05/fox/#ws- 
modestmaps which led to a lot more tinkering in Python-land as a way to create 
sexy vector based 

pinwins http://www.aaronland.info/weblog/2008/07/2 7/invisible/#historybc 
for other map-loving visualizations which finally led me to a train somewhere in 
Connecticut with no Internet connection and a wrapper library that doesn't rotate 



text. And three lawyers discussing inter-office strategery. 

Which is to say: I have now written even more code that I don't feel like 
porting back to PHP. 

So, in the absence of the actual data I needed to plot, I pretended that people 
and phone numbers were to my address book what the place names and 
page/marker indicators were to a table of contents in a pocketMMap. 

And rendered that text as a rasterized image. And rotated it. 

Please, tell it to the hand. 

By the time I got to Boston I not only had the workings to build the index 
pages for a pocketMMap I also had an easy to create phone book that doesn't 
require electricity to operate which, I know, is hard to imagine anymore. I couldn't 
tell you what my home phone number is without looking at my phone. 

Here's another unpleasant truth: Even when the network is "always" on, and 
even if you are comfortable sharing the contents of your address book with 
complete strangers like Google sync still 

SUCks http : / /www . r andsinrepose . com/archives /2008/11/2 5 /dumbing_down_the_ 

It's a genuinely hard problem but I have mostly given up trying to understand or 
care how and why programs like iSync sometimes work and more often don't. I take 
for granted the horror stories told by the iPhone users who have watched helplessly 
as their address books are deleted by the happy magic MobileMe cloud 
fairies http : / /www . tuaw . com/2 08/07/28 /mobileme-the-case-of -the- 
vanishing-iphone-contacts/ . I try to mitigate the inevitable synchronization 
disaster or database failures by routinely exporting everything to nothing more 
sophisticated that a text file and shuttling it between a variety of devices. 

Which includes paper, now: 

from pocketphone import pocketphone 

width = 8.5 
height =11 



number = {'name':'ray name', 'number': '999-999-9999'} 
out = " /path/to/my/pocketphone.pdf " 

ph = pocketphone( width, height, margin) 
ph . addnumber ( number ) 
ph. draw ( ) 
ph . save ( out ) 

Or if you are like me and use the totally excellent ab2vcard 

application http://scottstuff.net/ab2vcard/ to periodically dump the 
contents your address book database to a bunch of text files, you can do this: 

from pocketphone import vcard 

vcards = " /path/to/a/directory/fullof /vcards" 

V = vcard(width, height, margin) 
v . adddirectory (vcards ) 
v . draw ( ) 
v. savefout ) 

And then automate the whole thing with the magic of 
Cron http://en.wikipedia.org/wiki/Cron : 



# Every hour dump the contents of the address book database 

# At ten past every hour render the contents of that as a pocketphone book 

* * * * /usr/local/bin/ab2vcard -d /path/to/yer/abook/ 

10 * * * * /usr/local/bin/vbook.py -v /path/to/yer/abook -p /path/to/yer/abook/vbook.pdf 

Meanwhile. 

A few weeks later, in Montreal, I stood and watched as Raphael typed his 
number in to my phone http://www.grignani.org/thoughts/2008/11/five- 
doiiar-comparison.html . A month and some unremembered number of syncs 
later I went to call Raphael to coordinate a dinner 

plan http://flickr.com/photos/julianbleecker/3054753408/ only to 

discover that his number had disappeared from my phone. It's one thing when a 
rogue wave attacks you on the beach and soaks your phone before you've 
remembered to do a backup but otherwise it's genuinely irritating to have to be left 
wondering whether suddenly vanished data is due to a logic bug in your laptop's 
sync application or your phone's weird-ass and uncustomizable public/private sync 
settings or just a random attack of suck. Life is too short for this sort of thing. 
Nevermind trying to guess at the short list of phone numbers you might need to 
scribble down on a piece of paper just before the battery in your phone dies. 
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I mention all this not only because I was finally able to call Raphael having a 
"pocketphone" with me at the time or because the actual bits that created the 
pocketphone are the same bits used to the index pages for the Design Engaged 
pocketMMaps but because they're also a way to transform any old key-value list in 
to a handy booklet complete with (optional) categories. 

The very creatively named "pocketindex": 

from pocketindex import pocketindex 

# hey look! pixels instead of inches!! 
width = 300 
height = 500 

legend = { ' topright ' : ' vocabulary ' } 

data = [ 

{'label': 'challenge', 'value': '0 HAI ' , ' tags ' : [ ' lol ' , 'cat']}, 

{'label': 'response', 'value': '0 RLY ' , } 
1 

idx = pocketindex(width, height) 
pages = idx. create (data, legend) 
pages [ ] .save( " /home/asc /Desktop/test .png" ) 

Which is exciting only in that it's a tool. Not at all exciting. Until you need 
it. 



In theory, markers on a map should be the same. In practice there are always 
too many of them and they're always clustered too closely together. We are 
creatures of habit and given the chance we never shut up. This is reflected in our 



maps. It is a problem made worse by the tools used to build those maps not being 
able to adapt and keep pace with opportunities they create. The classic illustration of 
the problem remains red-dot fever http://mappinghacks.com/2006/04/07/web- 
map-api-roundup/ when a map contains so many markers that by showing them 
all the map itself is complete hidden. 




I don't have a working solution for this problem but I do know that instead of 
yet another pre-rerendered data layer that applies the same degree, or lack of, detail 
across all space I'd like to be able to generate map tiles that reflect the data being 
added to them. To "stop faking 

it http://mike.teczno.com/notes/de2008.html ", as Mike says . 

As usual, Mike is doing all the actual hard work particularly with tools like 
Cascadenik http://mike.teczno.com/notes/cascadenik.html which is all 
about hiding the pain of generating Mapnik http://www.mapnik.org/ 's XML- 
based stylesheets, from users and replacing it with a friendlier and more intuitive 
CSS-like syntax. (Mapnik is the rendering engine that the Open Street 
Maps http://blog.flickr.net/en/2008/08/12/around-the-world-and-back- 
again/ crew uses to produce their maps and the XML stylesheets describe the 
look and feel of the map tiles.) I would love it if I could generate those stylesheets 



on the fly passing them along with a request to a tool like 

mod_tile http://wiki.openstreetmap.org/index.php/Mod_tile and get back 

a freshly minted tile whose detail and definition are a function of the information I 
am trying to display. 
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ke Migurski: so like, driven by DPI? that sort of thing? 
ron Straup Cope: driven by DPI? 



ke Migurski: detail-based 

ke Migurski: or you mean more subtly controlled than that 

ke Migurski: a detail knob =) 

ron Straup Cope: stuff like : show all the large roads and 

only draw street names and other details in areas with a 
kers 

ke Migurski: ah 

ke Migurski: a detail spray can 
ron Straup Cope: yes :-) 
ke Migurski: detail hillshading 
ron Straup Cope: I am so copy-pasting this conversation in to the 



49 AH Mike Migurski: hehe 
01 AH Mike Migurski: detail brush 
:29 AH Aaron Straup Cope: yeah, like what maciej did but for the actual 



What I really want is for someone to build an on-demand EC2-style 

instance http : / /en . wikipedia . org/wiki/Amazon_Elastic_Compute_Cloud 

running that service which I could fire up and point my code (read: Modest Maps) 
at to get new tiles. I don't actually care whether it's EC2 or not. I'd prefer something 
I could run locally, like a stand alone Java 

daemon http: //www. aaronland.info/weblog/2 008/02/05/fox/#ws-decode , 
but given the dependency chain required to render tiles it seems that you still need a 
full-on fake computer/operating system rather than a sandboxed web application 
framework. 













Which is to say: Markers in pocketMMaps still only sort of work as a 
chicken-and-egg proof of concept. They get drawn to the correct spot on the page 
and there is some rudimentary repositioning done to ensure that markers don't 
overlap each other on the y axis. What's still missing, entirely, is code to handle 
markers that bleed off the top or side of a page (often as a result of being 
repositioned) or in to the crease between two pages. Because there's literally no 
room to do postermap-style raining 

markers http://www.aaronland.info/weblog/2 008/07/2 7/invisible/#historyb. 
I will probably need to sit down and brush up on labelling 

algorithms http: //www.eecs .harvard.edu/shieber/Biblio/Papers/gen- 

labei .pdf before any clever solutions present themselves. 

Which is to say: If you display a modicum of restraint selecting the points to 
include, it all Just Works. In fact, you can generate a fancy pocketMMap with 
markers and a table of contents from any old GeoRSS http://georss.org/ 
feed. 

Like this: 



from pocketMMap import GeoRSS 

mm = GeoRSS (width, height, margin) 

mm.drawf eed( 'http://maps.google.com/maps/blah/blah/blah' ) 



Which produces this: 
pocketmmontreal.pdf /webiog/2008/11/27/time/pocketmmontreai.pdf ! 

The code will automagically calculate the size of the bounding box of the 
map to draw based on the set of points in the feed and parse each description 
element looking for Stikkit-style "tag as" magic words. Each tag will be treated as a 
category and all the places associated with it will be included under that header in 
the index at the end of the pocketMMap. This way you can look up a restaurant, for 
example, by both its cuisine and its neighbourhood. The exception, or magic magic 
word, is the "skip" tag which will cause that item to be excluded from the 
pocketMMap entirely. Here's an example: 



<rtem> 

<guid isPerinaLink="false">00045657b554aedOb9388</guid> 
<pubDate>Mon, 08 Sep 2008 00:43:31 +0000</pubDate> 



<title>Cosmos</title> 

<description> 

<! [CDATA[<div dir="ltr"> 

Best greasy breakfast in town. Tiny and full of hangover-fighting 

grease . <brxbr> 

5843 Sherbrooke St west<brxbr> 

tag as skip resto breakfast ndg cheapeats 

</div>] ]> 
</description> 

<author>aaronofmontreal</author> 

<georss:point>45.4 694 4 -73 .618057</georss :point> 
</item> 

There is no good reason to continue (ab)using the description element for 
tags other than I started by using 

MyMapS http : / /googleblog . blogspot . com/ 2 07/04 /map-making-so-easy- 

caveman-couid-do-it . html and the wunderkids at Google still haven't added a 
proper tagging interface for the stuff you create there. Now that Dopplr has 
launched their new city pages http://biog.doppir.com/2008/11/27/new-city- 
pages/ I expect to see proper geo-enabled feeds for the corresponding tips 

pages http: //www. dopplr .com/place/ca/montreal/tips/tag/cof fee any day 

now (damn you, Matt Jones!) and I will add support for whatever goofy element 
they think is appropriate for tags. 



Were the pocketMMaps a raging success, in Montreal? 

Not at all, but they were a start and they helped prove some suspicions about 
how to proceed from here. One thing that was immediately apparent is that it's not 
at all obvious to most people how they are supposed to fold a PocketMod 

book http://flickr.eom/photos/straup/304 64404 98/#comment721576095375017: 

The PocketMod site seems to address this problem by making people watch a 
video http://pocketmod.com/ which is helpful but not terribly useful for a 
printed document. I seemed to remember that the 

Mapufacture http://www.mapufacture.com/ kids had included a how-to 
diagram with their 

pOCketmapS http : / /blog . mapufacture . com/ 2 008/0 7 /3 /pocketmaps-paper- 

maps-of-dynamic-data/ but in the end I never found anything to ask permission 
to use. So I made my own. 
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A handy how-to infographic is now included on the last page of both 
pocketMMap and pocketphone books and the source 

Omnigraffle http://www.omnigroup.com/applications/OmniGraffle/ file is 

included should anyone like to make improvements. I'm quite pleased with the 
illustration but then again I've been folding these things almost non-stop for two 
years http://aaronland.info/talks/#papernet SO I won't pretend to know 
where the stumbling blocks are anymore. 



Like everything else, the actual mechanics of how the diagram gets rendered 
are ugly and make you feel ashamed. Because PocketMod derived books can be 
printed on any sheet of paper than can be divided in eight there's no way to know 
what size a how-to diagram will need to be ahead of time. Originally, I had planned 
to include a copy of the diagram exported as SVG with the source code that could 
then be scaled and rendered, at runtime, using the 

SVglib http://pypi.python.org/pypi/svglib/ package. I'd still like to do this 
but that means first figuring out why the library always renders my SVG file as a 



blank image. 

In the meantime there are two kludgetastic workarounds and a third 
(hopefully) 80/20 default solution. If you have a copy of ws- 

raster http://www.aaronland.info/weblog/2 008/02/05/fox/#ws-raster (a 
standalone HTTP wrapper around the Batik SVG rendering engine) you can use that 
to create a nice and crisp rasterized diagram. If you don't and are printing on non 
US-letter sized sheets of paper there's a base64 encoded copy of a large PNG 
version of the image that will be scaled accordingly producing a workable but 
fuzzier diagram. The default, assuming that most people are going to be printing on 
either US-letter or A4 paper, was just to include a letter-sized base64 encoded PNG 
of the diagram produced by ws-raster and get on with it. 

Like I said, talk to the hand. Or submit a patch. 

You may have noticed that by now there's a pocketindex class, a 
pocketphone class and a pocketMMap class floating around. The first was always 
designed to be used by the others but since the last two were built in the margins of 
the day eyeing each other suspiciously there was a lot of code duplication (and even 
more badly named variables). The main reason it's taken so long to release anything 
since getting back from Montreal (aside from the "day 

job" http://code.flickr.com/blog/2 008/10/30/the-shape-of-alpha/ ) has 
been a desire to reconcile all that code and move the boring bits common to all 
PocketMod thingies like page layout, numbering and instructions in to a single 
shared package. You guessed it: pocketmod.py. 

Another code sample seems a little silly at this point but for thoroughness' 
sake if you wanted to generate a blank PocketMod book (with page numbers and the 
how-to infographic) you would do this: 

from pocketmod import pocketmod 

pm = pocketmod(width, height, margin) 

# this is the magic method that all 

# the other pm-derived packages call 
pm. layout ( ) 

pm. save (out) 

With the exception of ModestMaps which you'll still need to install 



Separately http: //modestmaps. mapstraction.com/trac/wiki/SubversionAccess 

(there's a proper installable version of the Python libraries in the works) all the 
packages now use the magic of 

SetuptOOlS http: //peak. telecommunity.com/DevCenter/setuptools which 

means any other dependencies should magically install themselves without any 
extra work from you. 

The shiny- shiny: 

• pocketMMap.py 

0.3 http: //www. aaronland. info /python /pocketMMap/pocketMMap- 
. 3 .tar. gz 

• pocketphone.py 

1.1 http: //www. aaronland. inf o/ python /pocketphone/poc ketphone- 
1 . 1 .tar. gz 

The gorey details: 

• pocketmod.py 

0.2 http: //www. aaronland. inf o/ python /pocketmod /pocketmod- 
0.2. tar. gz 

• pocketindex.py 

0.1 http : / /www. aaronland . inf o/python/pocketindex/pocketindex- 
. 1 .tar. gz 

What's next, then? 

Documentation, first of all. I've tried to make the user-facing code as brain- 
dead stupid as possible with sensible defaults but like all things it is starting to grow 
knobs so they should be recorded soon if only to save people having to read stuff 
like this just to know where to start. 



After that, there's some long overdue house-keeping to do for ws- 

modestmaps http://www.modestmaps.com/examples-python-ws/ including 

adding support for pin wins that contain arbitrary chunks of text instead of an image. 
This was another by-product of the Design Engaged pocketMMap: 

Boris http://bopuc.levendis.com/weblog , Molina http://missmoun.com/ 

and I were sitting around the night before the conference started and I foolishly 
suggested that we print a really big version of the pocketMMap with the names and 
descriptions of places in pinwins. That plan didn't work either because in my haste I 
chose poorly when trying to cluster places by proximity in order to produce a bunch 
of smaller maps, to compensate for Python running out of memory creating one 
monster image, and the aspect ratios were all out of 

whack http://flickr.com/photos/straup/2909846550/ . 



Oh well. I'll probably poke at that problem too eventually. 

Then maybe a brief detour to make some "turkishMMaps" for lack of any 
better name since people are excited by the Turkish Map 

fold http://flickr.com/photos/george/sets/72157609615207103/ these days 

and it shouldn't be very hard. I'm not in love with 



them http://flickr.eom/photos/straup/30380 7977 5/#comment72 157 6094 01858 0' 

but I'm hoping it will be a useful exercise in, dare I say it... brevity. 

It's (always been) clear that a four-page pocketMMap doesn't work but it's 
equally clear that any collection of personal or shared history will eventually grow 
beyond the upper limits of a single sheet of paper. So what to do? One idea I'd like 
to play around with is clustering the list of points by some measure of proximity — 
say by distance or mapping lat/long to a corresponding WOE neighbourhood 

ID http://code.flickr.com/blog/2008/09/04/whos-on-first/ — and then 
generating a smaller, shorter pocketMMap for each. That probably makes for more 
individual sheets to fold but also defers doing so until it's actually necessary and in 
the end, better maps to the way that we hold the overlapping facets and stories of a 
place in our mind. 




I think. 
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planes on strings 

When I get a zeppelin, I'm going to name it Myles 



When I get a zeppelin, I'm going to 
name it "Myles" 
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wow 

what is that? 

public display? 



PM 



Aaron Straup Cope: http://flickr.com/photos/straup/3134111134/ 

Mike Migurski 

Mike Migurski 

Mike Migurski 

Aaron Straup Cope: yeah 

Mike Migurski: 

Mike Migurski: 

Mike Migurski: 

Aaron Straup Cope: 

Aaron Straup Cope: 

Aaron Straup Cope: 

Aaron Straup Cope: 

Aaron Straup Cope: 
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23 PM 
35 PM 



12:52:44 PM 



awesome 

I love the height-thingies 

it's accelerated - is it on a loop of some sort? 
it seemed like it 
it was in a separate room 
with a big plate-glass window 
but everyone had gone home 

so I guess it was like a log fire for airports 
Mike Migurski: was it there for you? or for them? 
Aaron Straup Cope: both, I think 

Aaron Straup Cope: it looks like someone sits in there and pays 
attention 
Aaron Straup Cope: it wasn't clear 
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12:53:13 PM Aaron Straup Cope: it was in the joint between terminal 1 (not intl ) 

and the old abandoned terminal 2 
12:53:16 PM Mike Migurski: do little wooden balls fall down a chute each time a plane lands 
12:54:16 PM Aaron Straup Cope: it would be awesome if they used the lobby in terminal 2 to 

do a semi -realtime animatronic visualization of flight traffic 
12:54:31 PM Mike Migurski: planes on strings 

12:54:46 PM Mike Migurski: recorded sounds of children making jet noises 
12:54:46 PM Aaron Straup Cope: that's what they look like when you drive down the 101 
12:55:40 PM Aaron Straup Cope: "children making jet noises" — that would be a good name 

for an autobiography 
12:56:17 PM Mike Migurski: or a first album 
12:56:59 PM Aaron Straup Cope: or a conference 
12:57:16 PM Aaron Straup Cope: we should organize that 
12:57:19 PM Mike Migurski: UNconference 



12:57:23 PM Aaron Straup Cope: JETconf erence 
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